In maven2, how do I assemble bits and pieces of different modules to create final distributions?

Question

I have four maven project:

1. client api jar
2. web service war
3. ui jar
4. web interface war

The service war will need to be packaged to include the client api jar, together with javadocs (so that each version of the service is distributed with a bundled client jar and web documentation). The web interface war will need the ui jar and all the dependencies (webstart/applet deployment).

So I need a 5th project that does all the packaging. How to do this with ant or a script is perfectly clear to me, but not in maven.

I tried the following:

• having the javadocs included as part of the war packaging: this requires the execution of the javadocs goal in project 1 before execution of package in project 2. Haven't found a way to bind plugins/goals across different projects. Using the assembly plugin in project2 had the same problem.
• create a fifth project and use the assembly plugin. Still the same problems as before, with the problem that since I need different pieces from each sub-project I do not understand how this can be done using the assembly.

Is this too hard to do in maven, and should I just give up? Or I am looking at it wrong, in which case, how should I be looking at it?

Thanks!

---

Upon further reflection, here is a partial answer:

• Each project should build all its artifacts. This is done by having the plugins configured to run as per the prepare-resources and package phases. So, in my case, I prepare all that needs to be generated (jar, javadocs, xsd documentation, ...) as different artifacts so that a single "package" goal execution creates all. So, it's not "how project 2 forces project 1 to run different goals", but it's "make project 1 create all of its artifact as part as the normal lifecycle). This seems to simplify things.

Answer 1

The first thing i see in your description you are mixing things. Package the client api (package phase) no problem. But now you would like to make a client-api.jar which includes JavaDocs ? That's a little bit strange. Why not creating two artifacts (client-api-1.0.jar and client-api-1.0-javadoc.tar.gz ) ? The relationship between those two artifacts is the release number. This can be solved by taking a look into the Maven Assembly Plugin FAQ

The second thing you mentioned "web interface" this can be achieved with the assembly plugin as well (Take a deep look into the docs). May be you can post the pom's you have so we can help in a more detailed way.

BTW: You don't need ant for that. Maven can handle that.

Answer 2

The service war will need to be packaged to include the client api jar, together with javadocs (so that each version of the service is distributed with a bundled client jar and web documentation)

You'll need to create a source jar of the client project and to include this source jar in the configuration of the javadoc plugin in the war module. The steps and the configuration of the various parts are explained in Aggregating Javadocs from Dependency Sources.

The web interface war will need the ui jar and all the dependencies (webstart/applet deployment).

For the applet that needs to be downloadable, use dependency:copy to copy it at the "right" place inside your webapp during pre-package. See the usage page. For the webstart application, have a look at Add JNLPs apps to an existing WAR.

So I need a 5th project that does all the packaging (...) since I need different pieces from each sub-project I do not understand how this can be done using the assembly.

Using a dedicated module is definitely the way to go to create an assembly including artifacts produced by other modules or even assemblies of other modules.

I'm not 100% sure but creating an assembly of assemblies is probably what I would do here. Basically, this means setting up Maven to create an assembly of each module you want to assemble in the final bundle, possibly using the predefined assembly descriptor bin or a modified version (to bundle the jar, or war, the javadoc, etc). And then to assemble assemblies via assembly dependencies in an dedicated module (to unpack them, filter what you want or don't want, repack the filtered result). This will require to spend some time on a custom assembly descriptor but it's definitely possible. It's hard to be more precise though.