[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: Avoiding duplicate POM code: profiles, inheritance, properties Ron Wheeler Mon Apr 02 08:00:56 2012

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.

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.


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 
Thanks for the pointers.


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

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

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