On Monday, 25 November 2013, Barrie Treloar wrote:
> On 25 November 2013 20:32, Stephen Connolly
> <stephen.alan.conno...@gmail.com <javascript:;>> wrote:
> > be able to generate a pom for 4.0.0 clients that contains some of the
> > bug/features that some people seem to rely on, e.g. ${} expansion in
> > <dependencies>... but we don't need to maintain such guarantees when we
> > have a new schema.
>
> If there is a better way, then we should promote that and stop the broken
> way.
I was just addressing an issue with an example.... Perhaps I should have
been more explicit in the stating of the problem class
One of the points raised when evolution is considered is that there is a
bulk of projects that use hack A in order to achieve result X.
With a modelVersion 5.0.0 pom you will no longer be able to express hack A
but we will give a better way to achieve X (or we stick to our opinionated
flag and declare X as being a bad plan anyway and Y is actually what you
want)
In this class of problems, use if EL expansion in the <dependencies>
section is a common type of hack...
When experiments were made deploying resolved poms before (eg 2.1.0 or
2.2.0 I cannot recall which) it was found that the EL hacks were actually
being used for their side-effects... When the GPG signing problem was added
on top, the decision was to step back.
The point I am baking is that with modelVersion 5.0.0 we can revisit as we
can assume Maven 4.0.0+ for parsers only and thus maintain the *new*
contract.
If Maven 4.0.0 is building a modelVersion 4.0.0 pom then it will have to
deploy, bugs and all, the old pom in its entirety to keep backwards
compat... But we can retrofit .dml deployment onto the install and deploy
plugins so that a .dml gets deployed also (since that is an up-convert)
> > * There are valid cases where a parent pom can include a set of
> > dependencies that are common to all child projects. It may not be a style
> > that I like, but just as I am not going to give out if somebody writes
> > their *project* and has the idiotic idea of using TABs to indent (I'll
> moan
> > if I have to make a contribution to their project though) I do not think
> we
> > should prevent such a use case. Additionally, and perhaps more
> importantly,
> > there can be side artifacts for a pom packaging. Thus we really should be
> > publishing a .dml file for the parent. Most likely it will be empty (we
> > don't need <dependencyManagement> because .dml files *never* include a
> > parent reference) but the file is needed for any side-artifacts
>
> I think this is an area of confusion.
> There is a difference between a parent pom and a dependency inheritance
> pom.
> Too many times I've seen the parent pom have something "common" only
> to find out its not common in this grand-child over here.
> As above, If there is a better way we should be promoting that and
> stopping the broken way.
Well that is a different story... Mixins may be a different case also...
Schema change allows for Mixins too though ;-)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org <javascript:;>
> For additional commands, e-mail: dev-h...@maven.apache.org <javascript:;>
>
>
--
Sent from my phone
