• Home
  • RSS Feed
  • Log in

Migrating your project to maven 2 – PART III
Posted by Lars Vonk late at night: June 5th, 2006

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

 
<pluginRepositories>
<pluginRepository>
		<id>Maven Snapshots</id>
		<url>http://snapshots.maven.codehaus.org/maven2/</url>
		<snapshots>
			<enabled>true</enabled>
		</snapshots>
		<releases>
			<enabled>false</enabled>
		</releases>
	</pluginRepository>
</pluginRepositories>
 

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).

 
<dependencies>
    <dependency>
      <groupId>jaxen</groupId>
      <artifactId>jaxen</artifactId>
      <version>1.1-beta-7</version>
    </dependency>
 

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:

 
<preGoal name='junit-report:report'>
	<attainGoal name='clover:on'/>
</preGoal>
 

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

 
<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-clover-plugin</artifactId>
	<configuration>
<licenseLocation>${path}/clover-xebia.license</licenseLocation>
	</configuration>
	<executions>
		<execution>
<phase>pre-site</phase>
			<goals>
				<goal>instrument</goal>
			</goals>
		</execution>
	</executions>
</plugin>
 

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 http://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:

 
<settings>
...
	<servers>
	...
		<server>
		<id>ssh-xebia-repo</id>
		<username>username</username>
<privateKey>/path/to/ppkfile/file.ppk</privateKey>
		<configuration>
			<sshExecutable>/path/to/plink.exe</sshExecutable>
			<scpExecutable>/path/to/pscp.exe</scpExecutable>
		</configuration>
	</server>
 

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

<id>

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:

 
<project>
...
	<repositories>
		<repository>
			<id>xebia-repo</id>
			<name>Internal Xebia Repository</name>
			<url>http://url.repo.com/</url>
		</repository>
 

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):

 
<settings>
...
  	<servers>
  		<server>
  		  	<id>xebia-repo</id>
  		 	<username>username</username>
<password>password</password>
  		</server>
 

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

 
<project>
....
<packaging>war</packaging>
	<build>
	...
<plugins>
		...
<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-war-plugin</artifactId>
				<configuration>
				<warName>name-war</warName>
				<warSourceDirectory>src/web</warSourceDirectory>
				</configuration>
 

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:

 
<dependencies>
	<dependency>
		<groupId>javax.transaction</groupId>
		<artifactId>jta</artifactId>
		<version>1.0.1B</version>
		<scope>provided</scope>
	</dependency>
 

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:

 
<build>
...
<plugins>
	...
<plugin>
			<groupId>org.codehaus.mojo</groupId>
			<artifactId>weblogic-maven-plugin</artifactId>
			<version>2.8.0-SNAPSHOT</version>
			<configuration>
			<adminServerHostName>localhost</adminServerHostName>
				<adminServerPort>7001</adminServerPort>
				<adminServerProtocol>http</adminServerProtocol>
				<userId>${weblogic.userId}</userId>
<password>${weblogic.password}</password>
				<upload>false</upload>
				<remote>false</remote>
				<verbose>false</verbose>
				<debug>false</debug>
				<targetNames>${weblogic.serverName}</targetNames>
			</configuration>
 

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

 
<profiles>
<profile>
    			<id>weblogicConfig</id>
<properties>
      				<weblogic.userId>weblogic</weblogic.userId>
      				<weblogic.password>weblogic</weblogic.password>
      				<weblogic.serverName>dev</weblogic.serverName>
    			</properties>
  		</profile>
	</profiles>
	<activeProfiles>
  		<activeProfile>weblogicConfig</activeProfile>
	</activeProfiles>
 

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

mvn weblogic:deploy

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:

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

Filed under General, Java, Maven | 3 Comments »



3 Responses to “Migrating your project to maven 2 – PART III”



    Jan Says:
    Posted at: August 16, 2006 at 1:25 am

    Congratulations, you’ve got reporting working – I have a question specifically target at aggregated reporting for multi module projects. Is that something you’ve tried and got to work? Up until now, aggregating stuff really messes things up.



    Lars Vonk Says:
    Posted at: August 16, 2006 at 8:44 am

    No I haven’t tried that yet and I must say I am not suprised it messes things up. Our setup of the projects is not completly according to maven convention. We have a seperate project for each module, but are not using the multi module build from maven.



    mnemetica » Blog Archive » links for 2006-10-28 Says:
    Posted at: October 28, 2006 at 9:13 pm

    [...] Xebia Blog (tags: xebia blog article post migration maven2 artifact deployment wagon) [...]



Leave a Reply

Click here to cancel reply.

Deployment automation for Java application running on Websphere, WebLogic and JBoss

Archives

  • March 2010
  • February 2010
  • January 2010
  • December 2009
  • November 2009
  • October 2009
  • September 2009
  • August 2009
  • July 2009
  • June 2009
  • May 2009
  • April 2009

Xebia Sites

  • Xebia Corporate
  • Xebia France
  • Xebia India

Categories

  • Java (282)
  • Agile (109)
  • General (50)
  • Testing (42)
  • Performance (42)
  • Hibernate (36)
  • Scrum (33)
  • Podcast (31)
  • Architecture (31)
  • Spring (28)
  • SOA (24)
  • Maven (22)
  • Project Management (22)
  • Middleware (23)
    • Deployment (14)
  • Flex (17)
  • JPA (17)
  • Eclipse (15)
  • Xebia Labs (15)
  • Quality Assurance (14)

Tag Cloud

    Functional Programming Architecture Seam Testing Hibernate Java qcon fitnesse Grails JavaOne Spring Groovy Scala XML Agile Awareness Workshop Lean Ajax Scrum Introduction to Agile Poppendieck Maven Semantic Web Xebia Agile esb Closures IntelliJ Performance SOA product owner