I noticed a newer version of log4j (1.2.15) and figured I’d upgrade in our maven projects.

My advice is to avoid it… some unnecessary dependencies are forced so you end up with lots of extra jars. Hope they fix it soon.

After a good couple of days spent converting ant projects over to maven, here is what I consider the easiest method. This is using NetBeans 6.5rc1 but probably works in 6.1.

Here are the steps for converting an ant project to a maven project in NetBeans.
This presumes your ~/.m2/settings.xml is already set up (not shown here for security purposes) and you have installed the Netbeans maven2 plugin:

1. Open ant project
2. Create new maven project using the “Maven Quickstart Archetype”
3. Properties -> Sources -> Change to 1.6
4. pom.xml -> Add distribution management

<distributionManagement>
  <repository>
    <id>nexus</id>
    <name>Internal Releases</name>
    <url>YourInternalReleaseURL</url>
  </repository>
</distributionManagement>

5. Files tab -> src/main -> add folder “resources”. This will create an “Other Sources/resources” entry in the project view
6. Delete existing source and test package stubs
7. Copy java sources and test sources across from ant project
8. Move all config xml files (such as applicationContext.xml) over to “Other Sources/resources”
9. If you have any hibernate .hbm.xml files, create a folder structure under “Other Sources/resources” identical to the package structure, and copy the files to there
10. Resolve dependencies. The easiest way to do this is go through red-underlined classes, copy the missing required classname, right-click the libraries node and hit “Find Dependency”
11. If a dependency is purely for a test class, add “<scope>test</scope>” to reduce the resulting jar filesize
12. mvn install or deploy

If the ant project exposes a WebService:
1. Add the following plugin to the pom.xml:

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>jaxws-maven-plugin</artifactId>
  <executions>
    <execution>
      <goals>
        <goal>wsimport</goal>
      </goals>
      <configuration>
        <wsdlUrls>
          <wsdlUrl>yourWSDLExposedUrl</wsdlUrl>
        </wsdlUrls>
        <packageName>yourWSClientPackageName</packageName>
        <sourceDestDir>${basedir}/src/main/java</sourceDestDir>
      </configuration>
    </execution>
  </executions>
</plugin>

2. Change the wsdl location and packageName as necessary. Without the sourceDestDir, the generated sources live under target/ and code completion won’t work. Setting the package name to the same package as the ws-client solves this. Compilation works either way.

Earlier today, we noticed one the maven war files was being bundled with the geronimo-spec-javamail.jar. Unfortunately, the other projects use the standard java mail.jar. The presence of 2 seperate mail jars under the same tomcat instance has been causing us mime-type conflicts.

Hot-deploying worked though so we figured it was something to do with bundled jars.

In NetBeans, the geronimo jar appeared greyed out in the list of libraries, indicating a transitive dependency. How to work out which jar is at the root of this dependency?

1. Tools -> Plugins -> Install “Maven Dependency Graphs”
2. Return to project
3. Right-click the Libraries node and select “Show Library Dependency Graph”
4. Here, just type in the jar you want to trace and it reduces the graph to just a single tree

The plugin is still in beta, but it saved me lots of time so I would recommend it.

Update:

Unfortunately, this plugin was available in 6.5Beta but not in 6.5RC1. Hopefully it’ll make a comeback soon.