maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: Adding support for new dependency mediation strategy
Date Tue, 27 Aug 2013 08:46:15 GMT
On 27 August 2013 09:00, Jörg Schaible <Joerg.Schaible@scalaris.com> wrote:

> Hi Stephen,
>
> Stephen Connolly wrote:
>
> > On 26 August 2013 08:27, Jörg Schaible <Joerg.Schaible@scalaris.com>
> > wrote:
> >
> >> Hi Stephen,
> >>
> >> Stephen Connolly wrote:
> >>
> >> [snip]
> >>
> >> > It's better than that... I am not sure if I said it earlier or not, so
> >> > I will try to say it now.
> >> >
> >> > When we get the next format, there are probably actually three files
> we
> >> > want to deploy:
> >> >
> >> > foo-1.0.pom (the legacy 4.0.0 model)
> >> > foo-1.0-build.pom (the new 5.0.0+ model)
> >> > foo-1.0-deps.pom (the new 5.0.0+ model)
> >> >
> >> > Now foo-1.0.pom should be a resolved pom with only the bare minimum
> >> > required elements, e.g. dependencies and hopefully nothing else... may
> >> > need dependencyManagement, but I think we can collapse that down. No
> >> > <parent> element.
> >>
> >> OK, this works for releases, but what about SNAPSHOTs? For SNAPSHOTs is
> >> is quite normal that your parent is also a SNAPSHOT and you would
> produce
> >> all kind of problems if you try to resolve/collapse SNAPSHOT parents for
> >> SNAPSHOT artifacts that are installed or deployed.
> >>
> >
> > Why?
> >
> > Or perhaps you are confusing what I mean?
> >
> > Basically the foo-1.0.pom that gets deployed/installed is the result of
> > help:effective-pom with some bits removed, such as <properties>, <build>,
> > <reporting>, <profiles> etc
>
> I guess, you have your point by using different Maven versions. If someone
> uses a new POM model for his projects, it means that he will also use the
> new Maven. Any backward compatible POM seems in this case used only for
> projects using the older Maven and those will normally not rely on a
> SNAPSHOT.
>
> > When building from a checkout, the reactor will have everything... and if
> > you are depending on a deployed/installed -SNAPSHOT then the behaviour
> > will remain the same.
> >
> > And since this would be for a new Maven, we need only concern ourselves
> > that the contract of the new Maven's classpath and property behaviour is
> > correct... thus we don't have to preserve the current crazyiness when you
> > have a dependency that has transitive dependencies where parts of the GAV
> > are linked by properties.
>
> I hope, you're only referring to the usage of properties for the direct
> project version and the parent. In dependencyManagement (and
> pluginManagement) I really want to use distinct property constants ... it
> is
> so much more convenient and less error-prone.
>

I am saying that the properties being in the deployed *these are the
runtime dependencies* pom causes issues...

So that when deploying the foo-1.0-build.pom we would put in the EL
expressions... but when deploying the foo-1.0-deps.pom we would fully
resolve them to the property values at build time. (might have an exception
for the system scope's path... if we keep system scope) because that frees
the consumers from having to interpolate the properties and build the full
model.

In other words, we should make the -deps.pom easy to consume. The ${} EL
expressions are exactly what you want in the human authored files... just
not in the machine generated ones


>
> > In short, by separating the build time pom from the deployed pom, we can
> > maintain a defined reproducible behaviour[1] *and* migrate the schema
> >
> > [1]: That does not mean that Maven 4.0 will allow you to reproduce all of
> > the classpath hacks that you can with Maven 2/3... some of those hacks
> are
> > stupid (even if people insist on using them)... but it should mean that
> > whatever classpath constructs you can do in Maven 4.0 get mapped
> correctly
> > on a best effort basis to the legacy clients
>
> - Jörg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message