Mailing-List: contact ivy-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of Jim.Adams@sas.com designates
 149.173.6.152 as permitted sender)
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Subject: Using buildlist to generate a repo
Date: Tue, 6 Nov 2007 14:38:44 -0500
Message-ID: <688AEB1C4CF90D419DDE8D721005232B03AD154C@MERCMBX07.na.sas.com>
Thread-Topic: Using buildlist to generate a repo
Thread-Index: AcggrKSmScu5M6MRQ1eFYgN+MpdNYQ==
From: "Jim Adams" <Jim.Adams@sas.com>
To: <ivy-user@incubator.apache.org>

We have a set of external resources/jars that we need to put into a repo
to build our products. This set consists of more than one version of
some third party jars because some of our products use different
versions of these jars. I created ivy.xml files and build..xml files for
each of these in a directory structure that would allow me to use
buildlist to generate an Ant path that would allow me to publish them in
the correct order. Another by product of this is that I will end up with
a reproducible process that we can use to add new versions and new jars
to the repo.

This all seemed pretty straightforward to me so I was surprised when one
of the publishes failed because the other jars it depended on were not
in the repo. In examining the output I found that I had 2 versions of
Hibernate and one version of Hibernate_tools that I needed in the repo.
Only the latest version of Hibernate showed up in the repo.
Hibernate_tools required the older version and thus failed to resolve.

When I looked that the Buildlist task in ivy 2.0 (fairly current was we
are actually using a build from the trunk to try out another bug fix) I
found that Buildlist uses a linkedHashMap where the key is the name of
the module. Version is lost. Thus there is no way to do what I want to
do. Can you think of another way to do this or do I have to re-write
buildlist to handle this case?

Jim Adams
Jim.Adams@sas.com
Principal Systems Developer
SAS Institute