maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <>
Subject Re: Avoiding duplicate POM code: profiles, inheritance, properties
Date Fri, 30 Mar 2012 14:41:01 GMT
I read it to the end but I am not sure that I got it all.

One suggestion that we found helpful is to start to look at some of the 
maven projects as utilities that are really no different from a 
developers point of view than utilities that we use from Apache or 
Springframework or others.
They get their own lifecycle and live in our Nexus where all projects 
can use them as dependencies.

I am not sure why you have more than one deployment repo since you 
should be able to separate things out by their GAV and possibly classifiers.

Like you, each of our applications has a parent pom maven project and a 
bunch of maven projects that create
- jars that are dependencies for other projects
- jars that are executables
- wars that are webapps.

These are all held in the single repo since they all have unique GAVs.
There is no reason why each project could not have its own repo. I can 
only think of internal security or secrecy as generating this requirement.

I am not sure that I have advanced your cause in any way except perhaps 
in the area of separating applications from utilities.
Perhaps others who use OSGI might be able to advance the conversation a 
bit more.


On 30/03/2012 9:36 AM, Gillet Thomas (2) wrote:
> Hello all,
> I'm currently working in several projects using maven 3, and I need some help defining
a new POM hierarchy to avoid POM code duplication.
> My projects are composed of multiple bundles (it's OSGi based).
> Each project has its own deployment and source repositories and defines a different set
of bundles, but all bundles in all projects are sharing common basic configurations.
> Note: I don't use the word "project" in the meaning of "maven project" (that is, a project
is a bunch of bundles, each bundle being a single maven project).
> For now, each project is totally independent and has its own POM hierarchy:
> The "deployment" POM : top most POM, contains project specific properties (deployment
repository, scm, developers...).
> The "common" POM : next one in the hierarchy tree, contains common features (dependencies,
plugin configurations...).
> The "type" POMs : the third hierarchy level has several POMs, each one with features
for a specific bundle type (web bundle, persistence bundle...).
> The common POM and some of the type POMs have different profiles corresponding to different
build targets (onboard, offboard...).
> This way, each bundle defines its type by inheriting from the right parent, and building
for a given target is done through profile activation on the command-line (ex. mvn install
-P onboard).
> It is working, but, bundle types being the same for all projects, parent POMs are almost
> I just copy the POM hierarchy into each new project, changing only the properties of
the deployment POM.
> The build infrastructure and deployment process being still a work in progress, the POMs
are changing quite often and the maintenance of all those duplicated configs is becoming really
annoying. So here am I, looking for answers.
> What I would like to do is package all "technical" stuff (dependencies, plugin configurations)
in global POM(s) being shared by all projects,
> and leave management properties (the deployment POM) inside each project.
> What I tried:
> The current approach forbid this because the deployment POM is at the top of the hierarchy.
> Because there is multiple leaf POMs (the type POMs), putting deployment at the bottom
would need multiple project specific POMs, each one inheriting from a  type POM. Some kind
of "proxy" POMs adding properties along the way.
> But then deployment information would be duplicated. Not good enough.
> Unless there is a way to put those information in a property file, and use it in all
those proxys. But I don't know how to do that.
> I also tried to group all type POMs into one single POM with profiles.
> One profile by type, activated by a marker file in the inheriting bundle (didn't find
any other way to activate a parent profile from a child artifact).
> But then the target specific behavior is not working anymore, because profile activations
are ORed together, so I cannot create a profile running only for the "persistence" type AND
the "onboard" target.
> So this is not working either.
> Now, I start wondering if I'm not asking maven more than it can manage.
> Not the first time I struggle with its poor inheritance capabilities and the lack of
an "include" feature (heard about mixins, but seems it won't be there before a long time).
> Thanks in advance to all people who will reach the end of this really long post (if any).
> Regards,
> Thomas GILLET
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Ron Wheeler
Artifact Software Inc
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

View raw message