qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aidan Skinner <aidan.skin...@gmail.com>
Subject Re: RFC: Maven and the Java Build
Date Fri, 26 Jun 2009 11:09:45 GMT
On Fri, Jun 26, 2009 at 11:50 AM, Robert Godfrey
<rob.j.godfrey@gmail.com> wrote:

> I've not used Ivy, so I may be underestimating its cleverness; but I'm
> not sure how we can get away without the meta data being in effect a
> manually maintained duplicate of data that is mastered elsewhere.  In
> particular we want/require to build of versions of jars that are in
> our repo (so that we can have repeatable builds).  Thus the "metadata"
> is actually the version information pertaining to the jars that are
> actually checked in.  Are you saying that Ivy extracts version
> information from the checked in jars - or do we have to manually
> maintain a list of what jars are at what version?

We already maintain that, albiet build.deps encodes it into the file
name so it's not useful.

The idea is to teach ivy to look in lib/ for the jar, then we maintain
our deps in ivy.xml

Admittedly
commons-lang=lib/commons-lang-2.2.jar
is more concise than
<dependency org="commons-lang" name="commons-lang" rev="2.2"/>

But it's not a huge hardship if we can then guarantee meaningful poms
that are automatically generated.

If we did that, then downstream could concievably teach it to look in
/usr/lib/java or wherever to use system jars, which is what most linux
distros I'm familiar with strongly prefer.

- Aidan
--
Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org
"A witty saying proves nothing" - Voltaire

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


Mime
View raw message