Re: Avoiding duplicate POM code: profiles, inheritance, properties

It sounds like you are describing the usage of a parent POM.
A parent is a project specific POM that ideally carries your plug-in 
versions, deployment information and code versions for all of the POMs 
in the maven projects that makes up your application. Some of this is 
properties and some is full specifications.

This puts these decisions under the control of the project team and 
reduces the concerns of the individual developers and shrinks the maven 
project POMs by a lot.

You should read the docs on the usage of parent POMs.

Remember
1) A lot of people have built whatever it is that you are doing and 
there are Best Practices for doing it.
2) Maven has a very particular way of doing things and until you comply, 
you will be in a constant losing battle. "Resistance is futile".

Have a look at the list of Maven PMC members and the committers to see 
the quality of advice that you are getting.

Ron

On 02/04/2012 7:55 AM, Gillet Thomas (2) wrote:
> Hello Wayne,
>
> Seems my first post was really not clear. Trying to make it simpler:
>
> Basically, my main concern is to be able to package separately parts of the POM:
> - plugin configuration and/or dependencies (previously the "type POM")
> - distribution management information (previously the "deployment POM")
>
> So I can later define one set of distribution management information per 
> project, and one set of configuration per bundle type.
> Then each bundle will, depending on the project it is member of and depending 
> on its type, inherit from one set of distribution management information, and 
> from one set of configuration.
>
> Hope this is a better explanation.
>
> Then, about your proposals:
>
> > 1. Inheritance does not necessarily follow aggregation.
> That's right, I didn't think about aggregator POMs. Actually if properties 
> defined in an aggregator POM are accessible in the sub-modules, then it could 
> be a place to put shared properties for distribution management.
> But I'm not sure it is the case, and anyway it would make those properties 
> available only when building the aggregator. I need to be able to build each 
> module alone.
>
> > 2. The maven-remote-resources-plugin can help share resources (configuration 
> > files etc) between modules
> Didn't know that. But I need to share properties, dependencies and plugin 
> configurations, not only resources.
>
> > 3. Look into the "import" scope (but this really only helps managing 
> > dependencies, not necessarily useful to you)
> Didn't know that either, thanks to point it out.
> It actually could be used for the sets of configuration which only contain 
> dependencies, but when it comes to plugin configuration, again, not working.
>
> Not helping this particular problem I think, but that's indeed good thinks to 
> know.
> Thanks for the pointers.
>
> Thomas GILLET
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


--
Ron Wheeler
President
Artifact Software Inc
email: [EMAIL PROTECTED]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]