Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Users List" <users@maven.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4F75C5FD.1070903@artifact-software.com>
Date: Fri, 30 Mar 2012 10:41:01 -0400
From: Ron Wheeler <rwheeler@artifact-software.com>
Reply-To: rwheeler@artifact-software.com
Organization: Artifact Software
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: users@maven.apache.org
Subject: Re: Avoiding duplicate POM code: profiles, inheritance, properties
References: 
 <518BD89AF73FCF4FAF5D2E526C5A66340187D7E8F9@SEGOTC5146-CCR.vcn.ds.volvo.net>
In-Reply-To: 
 <518BD89AF73FCF4FAF5D2E526C5A66340187D7E8F9@SEGOTC5146-CCR.vcn.ds.volvo.net>
Content-Type: multipart/mixed;
 boundary="------------010405040503020008020501"

--------------010405040503020008020501
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.

Ron

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 identical.
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


--------------010405040503020008020501
Content-Type: text/plain; charset=us-ascii


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
--------------010405040503020008020501--