好久没玩Appfuse了,最近因为工作的原因,需要快速构建两个工程原型作sample之用,于是又想到了Appfuse.自Appfuse 2.1发布后这还是第一次使用,以下罗列了使用Appfuse2.1生成工程原型之后的一些“修剪”工作,以备后查。关于appfuse 3的常见问题请参考:AppFuse 3常见问题与解决方法 以及AppFuse 3的乱码问题
1.如果创建的工程是某个父工程的modular,不要直接在父工程下使用appfuse的archetype创建工程,否则创建出来的工程有错误。
2.如果使用mvn appfuse:full-source,只能在maven2下执行,在maven3下执行是无法成功的。
3.删除pom中的<resources/>中关于“target”的<resource/>部分,或者参考7,使用mvn org.apache.maven.plugins:maven-eclipse-plugin:2.6:eclipse 创建eclipse工程。
4.使用mvn appfuse:full-source生成源代码后,model、dao、service的并不在groupId.artifactId包下,而是直接在group包下,如果将这些包重构到groupId.artifactId包下,需要修改如下文件:hibernate.cfg.xml以及所有applicationContext*.xml文件,在这些文件中使用查找替换确保每一个包名都更正了。
实际上,我们可以直接绕过这个问题,方法是在使用archetype创建工程的时候,直接将groupId设为groupId.artifactId的形式,例如,如果我要创建一个groupId为net.sf,artifactId为demo的工程,我们可以将groupId设定为net.sf.demo,artifactId为demo,命令如下:
mvn archetype:generate -DarchetypeGroupId=org.appfuse.archetypes -DarchetypeArtifactId=appfuse-basic-struts-archetype -DarchetypeVersion=2.1.0 -DgroupId=net.sf.demo -DartifactId=demo -DarchetypeRepository=http://oss.sonatype.org/content/repositories/appfuse
待工程生成后,只需要将pom.xml中的<groupId/>改回net.sf即可。
5.整理spring配置文件
首先:删除\src\main\webapp\WEB-INF\applicationContext.xml,这里重复定义了关于compass的配置,但是记得要把
<bean id="compassPostProcessor" class="com.threeti.umax.mockapp.salesapp.webapp.search.CompassConfigurationPostProcessor"/>
拷贝到applicationContext-dao.xml文件中。同时建议把
/WEB-INF/applicationContext*.xml
/WEB-INF/cxf-servlet.xml
/WEB-INF/security.xml
的文件移到\src\main\resources文件夹下
修改在web.xml中关于spring配置文件位置的参数contextConfigLocation改为
<context-param> <param-name>contextConfigLocation</param-name> <param-value> classpath:/applicationContext-resources.xml classpath:/applicationContext-dao.xml classpath:/applicationContext-service.xml classpath:/applicationContext-struts.xml classpath:/cxf-servlet.xml classpath:/security.xml </param-value> </context-param>
同时记得修改所有测试用例父类中@ContextConfiguration中的spring文件名
补充(2014-8-19):对于为什么appfuse会分散放置spring配置文件的这个问题我是这样分析的:理论上这些文件放在WEB-INF下也可,放在resources下也可,分开放置可能是出于这样的考量:与WEB应用相关的配置如果放在WEB-INF下看似较为合理,比如:cxf-servlet.xml,security.xml等等,与后台业务处理相关的,如:dao,services的application context则放置在resources下,从安置位置的合理性上看这样做是比较规范,但是分散存放spring配置文件确实不是利于管理和查看,而实际上,如果我们看看一下使用appfuse生成的多模块工程,我们应该能够一下找到appfuse这样做的最主要出发点,即:让与WEB应用相关的spring配置放置在一个地方,让后台业务处理相关的spring配置放置在一个地方主要是为了方便appfuse生成工程!具体地说是为了在生成单一工程和多模块工程时不用调整文件位置!这也就能解释为什么在resources和WEB-INF下有两个一样的applicationContext.xml文件了!
6.关于单元测试报告testSearch(com.threeti.umax.mockapp.salesapp.webapp.action.UserActionTest)失败的问题
原因是org.compass.core.engine.SearchEngineException: Failed to rename index,对compass不太了解,目前还未找到解决方法,但不妨碍其他测试用例的执行。
7. 原pom中对于资源过滤的配置不是很好,我倾向于将需要配置的文件一一列出,这样比较明细。于是通常我会改为:
<resources> <!-- Filter jdbc.properties & mail.properties. NOTE: We don't filter applicationContext-infrastructure.xml, let it go with spring's resource process mechanism. --> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> <includes> <include>jdbc.properties</include> <include>mail.properties</include> </includes> </resource> <!-- Include other files as resources files. --> <resource> <directory>src/main/resources</directory> <filtering>false</filtering> <excludes> <exclude>jdbc.properties</exclude> <exclude>mail.properties</exclude> </excludes> </resource> </resources> <testResources> <testResource> <directory>src/test/resources</directory> <filtering>true</filtering> <includes> <include>jdbc.properties</include> <include>mail.properties</include> </includes> </testResource> <testResource> <directory>src/test/resources</directory> <filtering>false</filtering> <excludes> <exclude>jdbc.properties</exclude> <exclude>mail.properties</exclude> </excludes> </testResource> </testResources>
改动之后,在使用mvn eclipse:eclipse时可能会报 Request to merge when 'filtering' is not identical.这样的错误,据称这是eclipse插件2.7和2.8的bug,可使用2.6版本执行,命令如下:
mvn org.apache.maven.plugins:maven-eclipse-plugin:2.6:eclipse