Migrating your project to maven 2 – PART III

Maven 2.0.4 is out now for some time, so I decided to give it another go after an unsuccesfull attempt to migrate to maven 2 (with maven 2.0.3).
I am trying to migrate a WAR project, it has multiple dependencies to some artifacts that are provided by the maven repository, but also to ones that are not (e.g. sjsxp for streaming parsing). I will try to build and deploy the war application with maven 2.
And guess what? This time I got it working!

First let’s start where I got stuck last time: the reporting thing. As it turns out all reports we have now work in maven 2.0.4! Okay not completely out-of-the-box but it works! We have the following reports in our project:

1. checkstyle
2. javadoc
3. jxr (pmd)
4. surefire (unit test)
5. clover
6. pmd
7. jdepend
8. findbugs
9. simian

The last three reports are only available in SNAPSHOT versions from codehaus.org. Too make sure you can use SNAPSHOT versions you need to add the following to your pom.xml

	
		Maven Snapshots
		https://snapshots.maven.codehaus.org/maven2/
		
			true
		
		
			false
		
	

The findbugs plugin is missing the dependency to jaxen. The following dependency must be added in the pom.xml of the (MAVEN_REPO/findbugs/core-plugin/0.9.3/pom.xml).

    
      jaxen
      jaxen
      1.1-beta-7
    

I tried to add it in my own pom.xml but that did not work.The difference between configuring plugins for maven 2 in contrast to maven 1.x is that now all your configuration goes in the pom.xml (or the settings.xml).
For instance in maven 1.x you had to define the location of the license file for the clover plugin in the project.properties like this:
maven.clover.license.path=${maven.repo.local}/clover/licenses/clover-xebia.license
And the execution of clover could be defined in maven.xml as a pre goal like this:

As you know the project.properties and maven.xml no longer exists, so this is defined in the pom.xml as follows:

	org.apache.maven.plugins
	maven-clover-plugin
	
		${path}/clover-xebia.license
	
	
		
			pre-site
			
				instrument
			
		
	

Note that there is a <configuration> tag, where you can define the necessary config for the plugin you use. Check the plugin documentation for further information, see maven.apache.org/plugins/ or https://mojo.codehaus.org/. The <executions> tag contains information about when this plugin should be executed. Each execution defines its phases, when should it be executed, and the goals it needs to execute. For more information about phases check introduction-to-the-lifecycle. The above configuration makes sure that clover will instrument (compile with clover) all sources and create a fresh clover database. In our projects we also have dependencies that are not available from the maven repository, like the sjsxp-1.0.jar. We have an internal repository for these kind of jars. To install jars and generate the pom.xml for these kind of jars you can do the following (thanks to this execellent blog): Make sure you have generated a private key and public key and have something like pageant running. Then add the following fragment to your settings.xml file:

...
	
	...
		
		ssh-xebia-repo
		username
		/path/to/ppkfile/file.ppk
		
			/path/to/plink.exe
			/path/to/pscp.exe
		
	

I used putty tools for this and it worked fine (after Maarten helped me out). Then execute the following command on the command line (note that the value of the [xml][/xml] attribute and the -DrepositoryId are the same):
mvn deploy:deploy-file -DgroupId=sjsxp -DartifactId=sjsxp -Dversion=1.0 -Durl=scpexe://url/path/to/repo -DrepositoryId=ssh-xebia-repo -DpomFile=pom.xml -Dfile=sjsxp-1.0.jar
Now in order to download artifacts from you internal repository you can define your repository in your pom.xml as follows:

...
	
		
			xebia-repo
			Internal Xebia Repository
			https://url.repo.com/
		

When you enabled authentication you have to define your user name and password in the settings.xml as follows (note that the value of the <id> attribute are the same):

...
  	
  		
  		  	xebia-repo
  		 	username
  			password
  		

We can now test, run site and deploy artifacts to a remote repository. Now let’s create the WAR. This is fairly easy with maven 2. Just add the following to your pom.xml

....
	war
	
	...
		
		...
			
				org.apache.maven.plugins
				maven-war-plugin
				
				name-war
				src/web
				

The <packaging> attribute indicates that this project’s artifact is a WAR. Then you can add the maven-war-plugin and customize the default configuration. Then for example run mvn package, and the WAR is created.
When I created the WAR I noticed that the jta-1.0.1B.jar was included in the WAR. This is typically provided by the JEE (alias J2EE) server so I don’t want to include it in my WAR. As it turns out Hibernate has declared it as a dependency with the default (compile) scope (here is more information about scopes and dependencies) and hence it’s in my WAR. To not have it in my WAR I have to explicitly put in the dependency in my pom.xml with scope set too provided:

	
		javax.transaction
		jta
		1.0.1B
		provided
	

This way it’s available during compilation but not put in my WAR.
Our WAR runs on a weblogic server (8.1 SP4) and with maven 1.x we deployed it via the weblogic plugins. As it turns out this plugin is also available for maven 2. Here’s how you define it in your pom.xml:

...
	
	...
		
			org.codehaus.mojo
			weblogic-maven-plugin
			2.8.0-SNAPSHOT
			
			localhost
				7001
				http
				${weblogic.userId}
				${weblogic.password}
				false
				false
				false
				false
				${weblogic.serverName}
			

Because the userId and password can differ from installations this can be externalized in the settings.xml as follows:

           
  		
    			weblogicConfig
    			
      				weblogic
      				weblogic
      				dev
    			
  		
	
	
  		weblogicConfig
	

This goes for all properties you want to externalize, you have to create a <profile> and activate it in the <activeProfiles> section, there are other ways to activate it but that’s not relevant for now.Run [code]mvn weblogic:deploy[/code] and the application is deployed.
Finally we are done! I you are planning to migrate take note of the following:

• Reserve time to migrate to maven 2. Since there is no migration guide, expect for this little something, which is not much help.
• Dependencies are moved, most of the times the maven 1 location is still supported but who knows for how long. If a dependency is moved to a new location you will see messages like this in your console: [WARNING] While downloading servletapi:servletapi:2.3 This artifact has been relocated to javax.servlet:servlet-api:2. If you see this, just change the groupId and artifactId if necessary to the new location (the format of the message is: groupId:artifactId:version).
• The files build.properties and project.properties are replaced by settings.xml. It can be difficult too figure out where to put the properties that you have defined there. Some go in the pom.xml and some go in the settings.xml. Check all available documentation (google) and you’ll get there eventually.
• The same goes for maven.xml, allthough I haven’t migrated our customized distribution artifact (ant) script from maven.xml yet.
• In my opinion the maven home page (still) lacks clear documentation, so I uses google a lot.

Having all this said I would say it is save to start moving towards maven 2.0.4. There are no vague Exceptions on your console anymore and it all seems to work (maybe with a few SNAPSHOT versions of plugins but who cares).
References:

• https://www.coffeebreaks.org/blogs/?p=37, blog about maven 2 repositories.
• https://maven.apache.org/maven-settings/settings.html, the descriptor of the settings.xml file.
• https://maven.apache.org/ref/2.0.3-SNAPSHOT/maven-model/maven.html, the descriptor of the pom.xml.
• https://maven.apache.org/plugins/, list of available plugins.
• https://mojo.codehaus.org/, another list of available plugins from codehaus.