Maven and Eclipse code organization

Question

I'm new to Maven, and after having read the docs on the maven site and Sonatype's online Maven book, I'm still not clear on how to best organize things.

I have two apps, A and B which share code from mylib. Different developers work on apps A and app B, they are released independently. Before we started with maven, in Eclipse, I'd have a workspace with apps A and B and mylib. The classpath for app A contained mylib. If I made a change in mylib, pressing run within Eclipse, contained my latest changes.

In Maven, I can create a parent pom.xml, which references app A and mylib. But this makes mylib a subdirectory of app A. How can I keep one instance of mylib and not link the building of apps A and B?

We use SVN for our SCM

Thanks

Answer 1

You have multiple options, however, potentially the simplest approach would be to separate out mylib into its own Maven project with its own life-cycle. The benefit of this approach is that you can support having multiple versions of mylib and your apps A and B can reference different versions of mylib as needed. If mylib and appA are open in Eclipse (and mylib references the version of mylib you have open), you can build the application in the same manner as you did prior to using Maven.

This approach does not mandate any dependencies between the directory structures of the applications, so you could go with something similar to the following:

/myapps/mylib
/myapps/appA
/myapps/appB

The downside to this approach is that maven will not automatically build both appA and mylib (or appB and mylib) as they are treated as separate applications. However, this may not be much of an issue if your applications are using pre-defined and built versions of mylib (that have been uploaded to your local maven repository using "mvn install").

Here is an example of the POMs for these projects:

mylib:

<project>
  <modelVersion>4.0.0</modelVersion>

  <groupId>com.test</groupId>
  <artifactId>myLib</artifactId>
  <versioning>0.0.1</versioning>
  <packaging>jar</packaging>

  <name>mylib</name>

  ...
</project>

appA:

<project>
   <modelVersion>4.0.0</modelVersion>
  <groupId>com.test</groupId>
  <artifactId>appA</artifactId>
  <packaging>jar</packaging>

  <name>appA</name>
  ...
  <dependencies>
    <groupId>com.text</groupId>
    <artifactId>mylib</artifactId</artifactId>
    <version>0.0.1</version>
  </dependencies>
  ...
</project>

appB:

<project>
   <modelVersion>4.0.0</modelVersion>
  <groupId>com.test</groupId>
  <artifactId>appB</artifactId>
  <packaging>jar</packaging>

  <name>appB</name>
  ...
  <dependencies>
    <groupId>com.text</groupId>
    <artifactId>mylib</artifactId</artifactId>
    <version>0.0.1</version>
  </dependencies>
  ...
</project>

If you still want the convenience of a parent POM (one mvn package comment), then you could create a master pom in the /myapps folder similar to the following:

<project>
  <groupId>com.test</groupId>
  <version>0.0.1</version>
  <artifactId>myapps</artifactId>
  <packaging>pom</packaging>
  <name>myapps</name>
  <modules>
    <module>shared</modules>
    <module>appA</modules>
    <module>appB</modules>
  </modules>
</project>

This POM will automatically build myapp, appA and appB. If desired you could also create an appA and appB specific POM (pom-appA.xml). This is not the cleanest approach from a Maven perspective, but it will function. The only issue you would run into is if the version of mylib is not the version on which appA or appB is dependent. In that case your appA or appB code would be compiling against the version in your maven repository (if that version exists).

There are many other options you can use as well and I have seen plenty of discussions on Blogs and Wikis as to which is the best for various scenarios. However, it usually comes down to what works best for you and your organization. As long as it works and you are not going off building a custom, non-portable maven solution, then you are probably doing ok.

Hopefully this gives you some thoughts that you can use.