Loading...

users@maven.apache.org

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

Re: Avoiding duplicate POM code: profiles, inheritance, properties Curtis Rueden Mon Apr 02 08:01:59 2012

Hi Gillet,


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")
>

To me, it sounds like you are asking for multiple inheritance in POMs—or
else a non-inheritance-based include mechanism. AFAIK, Maven does not have
either of those capabilities.

Just like in Java, which is also single-inheritance only, it can be
difficult or impossible to avoid code duplication in certain complex cases.
But in my experience it is fairly rare, and often you can find an
alternative design that avoids the issue.

Does your project really need to "mix and match" the type and deployment
POMs in many different configurations? In other words, are you sure you
need a graph of POMs, rather than only a tree? As we all know, graphs can
be much trickier to deal with.

I suggest identifying the commonalities across most of your projects, and
including those in a common parent POM. In the case of dependencies and
plugins, ideally all projects will use the same versions of those anyway,
so they can largely be declared at the top level. In places where 9 out of
10 projects use version A, but the 10th uses version B, declare version A
in your toplevel, but override with B in the 10th project's POM. Then there
is no repetition, and you are consistent with Maven's "convention over
configuration" approach.

Maybe some day Maven will support some form of multiple inheritance for
adding in extra common configuration more efficiently. Until then, it
certainly is not perfectly DRY, but you can usually do fairly well.

Regards,
Curtis


On Mon, Apr 2, 2012 at 6:55 AM, Gillet Thomas (2) <
[EMAIL PROTECTED]> 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
>