Maven Analysis for DataONE

Does Maven replace or augment ant?

Maven is a separate product from Ant. The primary intention of Maven is dependency management as it relates to project builds. Dependency management without maven typically involves downloading and saving all definitive artifacts (such as shared libs or jar files) in the project workspace. If a version control system (VCS) is used, then all artifacts are then saved in the VCS repository. Maven provides the framework to automatically download all artifacts needed to build a project (shared libraries, jar files, etc) without having to save them in a VCS. Maven provides build, testing, deployment and distribution services for the project.

As a comparison, Ant is excellent at simply building a project but does not provide dependency management. But, Ant provides some tasks that are not included in maven. Maven has plug-ins that take advantage of ant’s capabilities during a build process. Therefore, ant is used as an add-on to Maven.

What is required to setup a build environment to utilize Maven?

From the development perspective, a developer will need to install maven. If the developer is using Eclipse and/or Netbeans, there are helpful plug-ins that preclude downloading and installing maven itself. For eclipse, the m2eclipse plug-in assists the developer to maintain the maven configuration files and dependencies needed for a project. An open source book, _Developing with Eclipse and Maven_ along with the documentation on the maven website should be all that is required to get started.

However, once using maven, there are certain standards that are expected to be conformed to. The directory structure for a maven project should conform to the standard maven template. If it is impossible, then the structure may be altered in a project descriptor.

pom.xml                       Maven configuration file
build.xml             Ant configuration file
src/                  Application and Testing structure
src/main/java                 Application/Library sources
src/main/resources    Application/Library resources
src/main/filters      Resource filter files
src/main/assembly     Assembly descriptors
src/main/config       Configuration files
src/main/webapp       Web application sources
src/test/java                 Test sources
src/test/resources    Test resources
src/test/filters      Test resource filter files
src/site              Site
target/                       Build directory
target/classes                Classes for Build

It is unlikely all these folders will be needed for every project, but if so, then please follow the above structure.

It should also be noted that maven will create a local repository of all downloaded artifacts in a .m2 directory of a developers home directory. If there is a unique configuration needed for a developers local repository, then they are saved in a settings.xml file.

Beyond Maven, there are other tools that we could use for our build environment, such as Hudson, a continuous integration application, and Sonar, a software analyzer. Hudson at the outset will be more important than Sonar. Although it is common practice to test and build a code base before committing change to SVN (right?), it sometimes becomes habit to check-in code before leaving for lunch or just on a whim. Given the potential that many hands may be working in a single code base, Hudson will quickly reveal a broken build. Sonar will become important when many more developers are involved, as with internships. Sonar will reveal is a baseline of good coding practices are being adhered to.

For a short case study see: .. __: http://www.g3it.com/technical/continuous-integration-on-sap-using-subversion-maven-hudson-nexus-and-sonar/

How will using Maven impact build of existing apps like Metacat and Mercury?

It should not impact the build of these products at all, unless the project teams would want to mavenize their build process (a very low priority I imagine, even if there is funding available). It may impact the distribution. If project builds are dependent upon Metacat and Mercury artifacts, then it would be best to include them in an artifact repository for ease of maintenance. If source code restrictions prohibit release of these artifacts to the public domain, then we will need to setup a private repository to hold the dependencies. From research, it appears that Nexus with the nexus-ldap plug-in google project would be the preferred choice.

What’s required to contribute to the public Maven repo?

A project should be configured to deploy to a remote repository (such as sourceforge or one maintained by DataONE). As I mentioned above, Nexus appears to be the best for internal purposes. I am uncertain if we have a desire to use a publicly available services such as sourceforce for releases.

Otherwise, there is a minimal set of metadata that must be maintained in the pom.xml (maven configuration file). The remote repository must have rsync or rsync over ssh. Then an issue must be opened in .. __: http://jira.codehaus.org/browse/MAVENUPLOAD and a csv file attached with all relevant information.