HowTo: add more than one source directory into a maven build

29 07 2009

There are more project builds that use code generators to convert model files or interface descriptions into code and associated resources. The normal approach is to generate the code every time and place it in the …./target area of the build so that its gets built duging maven’s compile phase. However there are times when you want to generate the code rarely, and have it form part of the code base. If this is the case, then putting it in the man source tree, with all the hand crafted code can be dangerous and confusing. Ideally generated code, even if you keep it for a long time, should really go in its own source tree. eg …/src-generated.

The problem is, by default, maven only allows one source tree per project, and building a jar just for the generated code base might be too painful. There is no standard pom way of adding further source trees into the main maven build, but there is the maven build-helper-maven-plugin, that can amongst other things, inject additional source and resource locations into the build. The example below adds generated sources, tests and resources into a standard build.

<plugin>
 <groupId>org.codehaus.mojo</groupId>
 <artifactId>build-helper-maven-plugin</artifactId>
 <version>1.4</version>
 <executions>
   <execution>
     <id>add-wsdl-source</id>
   <phase>generate-sources</phase>
   <goals>
     <goal>add-source</goal>
   </goals>
   <configuration>
     <sources>
       <source>${basedir}/src-generated/src</source>
     </sources>
   </configuration>
 </execution>
 <execution>
   <id>add-wsdl-test-source</id>
   <phase>generate-sources</phase>
   <goals>
     <goal>add-test-source</goal>
   </goals>
   <configuration>
     <sources>
       <source>${basedir}/src-generated/test</source>
     </sources>
   </configuration>
 </execution>
 <execution>
   <id>add-wsdl-resource</id>
   <phase>generate-sources</phase>
   <goals>
     <goal>add-resource</goal>
   </goals>
   <configuration> 
     <resources>
       <resource>
         <directory>${basedir}/src-generated/resources</directory>
         <targetPath>target/classes</targetPath>
       </resource>
     </resources>
   </configuration>
 </execution>
 </executions>
 </plugin>




Automated Testing

14 07 2009

JUnit testing and integration testing is all very well, but being within the same JVM generates some level of synchronization even if effort has been taken to isolate the testers from what is being tested. Frequently there is also a level internal knowledge shared between the tester and the tested, which blurs the API being tested.

With REST based services life becomes easier. Take the work that is being done on Sakai K2, an Apache Sling based application. One developer with a passion for QA, Daniel, is writing perl scripts to exercise the published REST API’s from the Java developer team. Being totally disconnected from the Java VM, and building tests to the agreed API, its hard for the Java team to argue with test failures, and there is a certain pleasure in hitting an area of the code base with 10 external threads that you know have a level of randomness that would not be possible with in JVM tests. It surprising the ease with which concurrency issues can be exposed, but better now than in full production. At last count there were about 200 tests giving nearly complete coverage of the code base beyond Sling.





Reloading OSGi

6 07 2009

If you want to break an OSGi container, just reload a utility library with static methods, that other things depend on… my experiance has been the whole container grinds to a halt only to be recovered by a kill. YMMV.