hudson + maven +svn 持续开发测试平台

 

1.安装jdk
2.安装maven
3.安装tomcat
4.把hudson.war  放到tomcat 发布程序目录下

5。登录hudson 地址：hppt://localhost:8080/hudson

6.首次登录会让下载需要的插件、svn的、deploy的等
7.完成插件安装 配置hudson的系统设置，主要是jdk设置、maven设置
8.新建任务，主要配置svn、deploy war的配置
  配置svn url的时候 是支持 svn：和http两种方式的，跟插件的版本有关系，而且hudson的容器tomcat要配置URLEndding 为UTF-8，才会支持带中文的 svn地址
  配置tomcat的时候，需要tomcat的用户名和密码，这块是需要配置tomcat的tomcat-users.xml文件的，把用户配置那的注释去掉，并且tomcat用户要拥有manager-script角色

  <role rolename="tomcat"/>
  <role rolename="role1"/>
  <user username="tomcat" password="tomcat" roles="tomcat,role1,manager-script"/>
  <user username="both" password="tomcat" roles="tomcat,role1"/>
  <user username="role1" password="tomcat" roles="role1"/>
另：tomcat会报内存溢出；

PermGen space
进行清理，所以当我们的应用中有很多的class时，很可能就会出现PermGen space的错误。
    解决方法：
 1. 手动设置MaxPermSize的大小
    修改 TOMCAT_HOME/bin/catalina.bat(Linux上为catalina.sh)文件，在非注释区第一行
JAVA_OPTS="$JAVA_OPTS -Xms512m -Xmx1024m -XX:PermSize=256M -XX:MaxPermSize=512m"

加jdk环境变量：
用文本编辑器打开/etc/profile
·在profile文件末尾加入：
export JAVA_HOME=/usr/java/jdk1.6.0_14
export PATH=$JAVA_HOME/bin:$PATH
export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar

source /etc/profile（该命令使 环境变量生效）

 

 

9.在windows 环境下，hudons重复部署时 ，会不成功，不能完全删除 部署项目 中的文件，导致 hudson重新部署失败

   解决：大概是因为Tomcat还在使用这个目录，无法删除，必须修改$TOMCAT_HOME/conf/context.xml：

<Context antiJARLocking="true" antiResourceLocking="true">

说明： 

Tomcat中antiResourceLocking和antiJARLocking的作用

 

Tomcat应用更新时，把新的WAR包放到webapps目录下，Tomcat就会自动把原来的同名webapp删除，并把WAR包解压，运行新的 webapp。

但是，有时候Tomcat并不能把旧的webapp完全删除，通常会留下WEB-INF/lib下的某个jar包，必须关闭Tomcat才能删除，这就导致自动部署失败。

解决方法是在<Context>元素中增加一个属性antiResourceLocking="true" antiJARLocking="true"，默认是"false"。

这样就可以热部署了。

实际上，这两个参数就是配置Tomcat的资源锁定和Jar包锁定策略。

 

（1）antiJARLocking

先来看看应用的antiJARLocking属性设置为true时，Tomcat是怎么处理的。

针对antiJARLocking属性的处理集中在WebappClassLoader的getResource和findResourceInternal方法里，主要原理是将包含在Jar包里的资源抽取放到应用的工作目录（work里应用对应的目录）下去。

把这个属性设置为true之后，部署应用就可以在work\Catalina\localhost\struts2-blank\loader目录下看到被解压的Jar包内容。

antiJARLocking属性在有的时候并不会生效，从WebappClassLoader的getResource和findResource方法逻辑里可以看出一些端倪，在一些情况下（通过对Loader的delegate、searchExternalFirst等相关属性进行配置），资源的获取并不是WebappClassLoader去做的，而是其父加载器的getResource方法或父类的findResource方法去做的，WebappClassLoader的父类是URLClassLoader、父加载器是URLClassLoader实例。

（2）antiResourceLocking

当antiResourceLocking设置为true的时候，Tomcat不会锁定应用下的任何文件。那Tomcat是怎么做到这一点的呢？

在Tomcat的架构里，应用也是一个级别的容器，对应的接口是Context；各级容器本身都具备生命周期，而且配置了多个生命周期监听器来监听容器不同的生命周期过程。Tomcat在初始化的时候，给Context增加了一个生命周期监听器org.apache.catalina.startup.ContextConfig；然后在Context真正开始启动之前，会有一个BEFORE_START_EVENT状态，ContextConfig监听到这个状态的事件后，就会针对antiResourceLocking进行处理。

总结一下，就是如果应用的antiResourceLocking属性设置为true，就将应用的doc base移到临时目录下，让Tomca不会占用webapps下的文件。Tomcat里java.io.tmpdir默认指向Tomcat的temp目录。

副作用

 

 

从上面的分析来看，antiResourceLocking为true有几个副作用：

1) 会延长应用的启动时间，因为多了临时目录的清理和往临时目录拷贝应用内容的操作；a

2) 如果不知道这个属性的原理，修改webapps下应用的JSP，那就不会动态重加载到新的页面内容了，因为应用的doc base已经不再在webapps下了；

3) 停止Tomcat的时候，临时目录下实际的doc base会被删掉，

结合第二条和第三条，如果要修改应用的JSP，那必须将改动同时拷贝到两个目录下（原始doc base和临时目录下的doc base）。

所以Tomcat里这个属性缺省为false。在使用Tomcat 6.0.24之前的版本时，如果要用这个属性解决文件被锁的问题，三思而行。