maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "jon.mithe" <>
Subject Re: Custom assembly of multi module project
Date Fri, 12 Nov 2010 17:23:31 GMT

Thanks again for all your help, although I've come up with a slightly
different solution.   Was not comfortable splitting the config + jars up,
especially as I am going to have a minimum of 20 odd modules in this project
(its fairly large / diverse).

So if anyone is interested / has this problem this is what I did:

I used the src/main/resources folder of each module. In there I have created
3 folders mpApp-root, myApp-config, myApp-otherConfig (well, not those exact
names). Each module / artifact is a jar. with that inside, e.g:


I created another module (myApp-dist) and made it depend on all other
modules I want to distribute in my test build (eventually this will probably
be a separate project). Its the pom in this module I define my overall

The build defines 3 custom assemblies:

1. uses dependencySet with exclude "myApp-*/**" to jar up all dependencies
into a monster jar.  i.e. I get just a jar of all classes without special
resource folders.
2. uses dependencySet with include "myApp-*/**" to just includes the myApp-*
special folders, this assemble outputs to format "dir".
3. Defines filesets to include in a tar.gz. So the main dist jar created by
the 1st assembler and then all the special folders.  The cool thing is you
can define the output directory so myApp-root contents goes to ./,
myApp-config goes ./config etc.

The result is along the lines of a tar.gz with contents:


Sucks a little creating special folders that do magic things in the build
but its not too bad.  One odd little side effect is putting a - in the
resource folder name means it cant be used as a java package... handy to
ensure some random java package does not clash with a special folder and
accidentally get its .class excluded from the dist jar.

Also to get this building and packaging locally, mvn install is quite a
useful command :P

Tried gradle, think it had the potential to suit my build better but
ultimately using it with eclipse, defining new modules etc, it was clunky. 


Jon Paynter wrote:
> On Tue, Nov 9, 2010 at 8:34 AM, jon.mithe <> wrote:
>> Interesting.  I think I have found some unpacking elements in the
>> assembly
>> plugin when I write my own descriptor.  So it may be possible... needs
>> more
>> research.
>> I think I understand what you are saying about separating the config from
>> the binaries.  But I'm not sold on the idea of creating it in a different
>> project.  The way I'm trying to do it, the code + the config is
>> completely
>> separate, i.e. its not jar'ed with the classes and I do not have any
>> issues
>> with duplication.  The code and the config is a tightly linked enitity so
>> I
>> feel uneasy about splitting them into 2 separate projects (albeit linked
>> by
>> a dependency).
>> What concerns me most is I feel that doing it this way would be a work
>> around for the way maven builds, i.e. I'm starting to think my project
>> does
>> not seem to fit nicely with maven way of doing things :/
>> Thanks again for all you help, I'm not giving up on maven yet but I think
>> I
>> need to take a more in depth look at gradle and see if it fits this any
>> better.
> I recently finished solving a very simmilar problem. with trying to
> package
> things.  Before conversion to maven, the structure looked like this (yes
> its
> using ant)
> Parent Project
> --Common configs
> --Module A
> ---- moduleA.jar
> ---- moduleA.ear
> ---- moduleA.war
> ---- src/config
> ---- build.xml
> --Module B
> ---- moduleB.jar
> ---- moduleB.ear
> ---- moduleB.war
> ---- src/config
> ---- build.xml
> /dist/ModuleA/ModuleA.ear
> /dist/ModuleA/config/
> /dist/ModuleB/ModuleB.ear
> /dist/ModuleB/config/
> Once all the dust settled, I ended up with a structure like this:
> Parent Project
> --Common Configs
> ----src/main/other_resource_directory
> --Module A
> ----src/main/config
> ----ModuleA_jar
> -------src/main/java
> ----ModuleA_war
> -------src/main/webapp
> ----ModuleA_ear
> -------src/main/META-INF
> ----ModuleA_Package
> -------src/main/assembly
> -------target/
> --Module B
> ----src/main/config
> ----ModuleB_jar
> -------src/main/java
> ----ModuleB_war
> -------src/main/webapp
> ----ModuleB_ear
> -------src/main/META-INF
> ----ModuleB_Package
> -------src/main/assembly
> -------target/
> Packaging_project
> ---target/dist/ModuleA/ModuleA.ear
> ---target/dist/ModuleA/config/
> ---target/dist/ModuleB/ModuleB.ear
> ---target/dist/ModuleB/config/
> The key here was first to seperate things out so each project produces
> exactly one _binary_ artifact.  Then to seperate the packaging/assembly
> from
> the compiling.
> In moduleA_package and moduleB_package, the resulting zip file is marked
> as
> attached, so it gets stored in the repository.
> the packaging_project then depends on only whats needed to distribute -
> which is just the zip file.  The zip file is unpacked into its proper
> directory.
> the moduleA_package and moduleB_package are assemblies that do filtering
> and
> copying of the config files.  its not a very elagant solution to the
> common
> configs, but it does work.

View this message in context:
Sent from the Maven - Users mailing list archive at

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message