Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
Received-SPF: pass (nike.apache.org: domain of aheritier@gmail.com designates
 209.85.128.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CA+nPnMyL7YJx=ikTig+mRr5ewQ3RZBrRp2788JzxPku8yQZY9g@mail.gmail.com>
References: 
 <CA+dWQFos=6a7NtVY_z31yEvjYNKBUF=ZbWaqMXkE_2pTBC_kZg@mail.gmail.com>
 <kv0m8u$gh4$2@ger.gmane.org>
 <CA+dWQFpHZFXGe9mPS489cToNMC9e0Ym+8Pq=RAwd1xCu5wFZJg@mail.gmail.com>
 <CANWgJS4e3EXBJ1gQwTieFSPj0cYfSGKcr0ZcX5_F7KNwM590=A@mail.gmail.com>
 <CA+dWQFpdFeW3p-Mefmh9YG231KdxWHcKcR6D=Q-+tTZ0WRV6vg@mail.gmail.com>
 <C84F31C8-6602-476A-8066-E50F5C07DA7E@talios.com>
 <CA+dWQFpf1Mb1fSK--SYc6Lf9Pf+n+tg4sL2ZhCu+_oA2HBQy4A@mail.gmail.com>
 <CA+nPnMwiDA=KoC1RbVhbh9Hu+AqVFkm+ec=e_QcAA06DQXR1Ng@mail.gmail.com>
 <CA+dWQFqeDyEKFOH7jx1pT7J-SpUGbLDFWp0Cv8+6+G-qCFhQUA@mail.gmail.com>
 <FA0D71AE-ED19-4B02-B7C6-DF9A85E2BF14@talios.com>
 <0036F617-0988-4B47-8F2E-358E28BF1C37@fortysix.ch>
 <56BFBEAC-178F-44F5-90A0-95F487E05CDD@talios.com>
 <CA+nPnMyOCkP6a-cYZeUBAuzXfNNQwsuep5Crg-4puFRUB+fYrg@mail.gmail.com>
 <op.w19yif2jkdkhrr@columbia>
 <CA+nPnMxa1rzfmhJJi+0rEznMmV5nPMsZVkujVZ-m1_+qkRaruQ@mail.gmail.com>
 <kvf009$cgp$1@ger.gmane.org>
 <CA+nPnMyL7YJx=ikTig+mRr5ewQ3RZBrRp2788JzxPku8yQZY9g@mail.gmail.com>
From: =?ISO-8859-1?Q?Arnaud_H=E9ritier?= <aheritier@gmail.com>
Date: Mon, 26 Aug 2013 10:06:21 +0200
Message-ID: 
 <CAFNCU-_vGNRKfBuzWEDoUZ3Q9VcQqaGvECEN4dL4Ha_aELGvTQ@mail.gmail.com>
Subject: Re: Adding support for new dependency mediation strategy
To: Maven Developers List <dev@maven.apache.org>
Content-Type: multipart/alternative; boundary=047d7b604eb28522b804e4d53c52

--047d7b604eb28522b804e4d53c52
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I think it doesn't work if you have several level of inheritance in
different projects and you don't republish all intermediate artifacts
Let's imagine you have projectA <-- inherit <-- projectB <-- inherit <--
projectC
If all of them are in SNAPSHOT for now if you change projectA and republish
it, you'll access to your changes in projectC
With the resolution you'll have to wait to have projectB republished to use
the change in projectC.

No?

Arnaud


On Mon, Aug 26, 2013 at 9:55 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> On 26 August 2013 08:27, J=F6rg 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, s=
o
> 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... ma=
y
> > > 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
>
> When building from a checkout, the reactor will have everything... and if
> you are depending on a deployed/installed -SNAPSHOT then the behaviour wi=
ll
> 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.
>
> 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 ar=
e
> 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 correctl=
y
> on a best effort basis to the legacy clients
>
>
> >
> > [snip]
> >
> > - J=F6rg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>


--=20
-----
Arnaud H=E9ritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

--047d7b604eb28522b804e4d53c52--