log4p

I'm helping a group of students to split up their codebase into a couple of manageable project using maven2 as the build tool. Their existing project is a layered Spring MVC web application. The following layers are present:

• data model
• dao / integration
• services
• web application 1

Since dependencies where not managed yet the codebase managed to drift into containing spring 2 and spring 1.2.6 libs without anybody overseeing the classpath... something maven should really help to fix.

Once you've got maven2 installed it is quite easy to setup a project structure which packages and versions of the different layers in different libraries (jars) so they can be reused for different purposes.

First we'll define the parent project, which will contain dependencies and configuration shared between all layers:

mvn archetype:create -DgroupId=wosi -DartifactId=wosi

This will create a directory with the artifactId as name containing pom file (project object model) and a source directory. We won't need the source directory so it can be wiped.

Since the parent project will aggregate a couple of 'modules' the packaging should be changed from the default 'jar' to 'pom':

We can leave the dependency on junit, since we'll use it in all projects.

Now, if we create projects from the previously generated directory they'll be registered as 'modules' automatically. Let's create the different projects. From the command line run:

Now if we look at the parent pom we'll see the different module entries:

And all module poms will contain a reference to the parent:

Now it's possible to compile or install all projects from the root directory of the project (mvn install) or you can compile any of the subprojects separately.

Useful commands to know are:

• validate : validate the project is correct and all necessary information is available
• compile : compile the source code of the project
• test : test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
• package : take the compiled code and package it in its distributable format, such as a JAR.
• integration-test : process and deploy the package if necessary into an environment where integration tests can be run
• verify : run any checks to verify the package is valid and meets quality criteria
• install : install the package into the local repository, for use as a dependency in other projects locally
• deploy : done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.
• clean : cleans up artifacts created by prior builds
• site : generates site documentation for this project

By default subprojects are not dependent on any of the other projects, it is however quite easy to create dependencies. For instance, say I want to have a dependency from my service layer on my integration layer. Just at it to the pom of the service project:

Using the projects in Eclipse
It is possible to use the projects in Eclipse without any modifications (make sure to configure eclipse correctly though). Just run 'mvn eclipse:eclipse' from the root and import the generated projects using eclipse. If you would however like to use Eclipse's web tools to deploy webapplications a small modification to the parent pom is needed, ad a wtp configuration to the build/plugins section:

Now, after generating the eclipse projects again all web projects in the project should get configured for WST.