Mailing-List: contact repository-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: repository@apache.org
Received-SPF: pass (herse.apache.org: domain of xavier.hanin@gmail.com
 designates 64.233.162.237 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=aj8wPTmgBwNlxQGSn8YFGRkayAaJzmdu8LgIH8PcopGAu5Za8rixPwxu3t924zmJ2sr2FyEm6AXlwNsxvVB3MkSdK3wAkAghWNfmTTQ+zS0TuPUIBDYQVMq/009MOz/BPd4mj1fSNa6bRvbrtOnlRu4NBl/FTnYcCPbSeFoEmE4=
Message-ID: <635a05060705220334q3f9ffb1ckbedb735c2d2a2dbb@mail.gmail.com>
Date: Tue, 22 May 2007 12:34:53 +0200
From: "Xavier Hanin" <xavier.hanin@gmail.com>
To: repository@apache.org
Subject: Re: what does ${version} do in a POM
In-Reply-To: <c84a50780705220324x679528e8o1f7c36400a594f9c@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <c84a50780705210743u19bdb9b1x7c6b84d879857e0e@mail.gmail.com>
	 <adba96190705210855l1996c7d0xba68e8a20e6ff94f@mail.gmail.com>
	 <262c6c680705211842s2c7b84cap93ba67d467b904ea@mail.gmail.com>
	 <c84a50780705220134n626f5cc1q5ef232e51e20d04c@mail.gmail.com>
	 <635a05060705220214j1e419893h1cbaac8048adb8fb@mail.gmail.com>
	 <c84a50780705220324x679528e8o1f7c36400a594f9c@mail.gmail.com>

On 5/22/07, Steve Loughran <steve.loughran@gmail.com> wrote:
> On 22/05/07, Xavier Hanin <xavier.hanin@gmail.com> wrote:
>
> > BTW I agree with steeve, published metadata should be self contained
> > with no reference, it would make tool development much easier and much
> > more stable and reproducible. It's nice to know this has been done in
> > maven 1.1.
>
>
> If you were to be fully rigorous, you'd do a complete closure of the
> dependency graph, so the metadata of every artifact would list the
> dependencies as resolved by the build tool at the time of release.
> That way you don't have to "think like a turtle" and reimplement the
> resolution logic of the specific tool used just to get the
> dependencies. It would also be a nice regression test for resolution
> code...if you resolved the pom and came up with something different
> from the closure, you'd know your algorithm was broken.
Interesting, I've already people looking for something like that to
ensure an even stronger reproducibility (not relying on other metadata
in the repository). But this would need to be something well defined
as being a closure, so that you don't loose the information of why you
have one dependency: ie which module actually depend on it. Another
problem is conflict resolution. One module may choose to use a
different conflict resolution mechanism which would need to recompute
the dependency closure.

Xavier
>
> -steve
>


-- 
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/