I have this working for my build level classes. In this case, my properties
file has lucene.v1=/lib/lucene-version1/lucene-version1.jar and then in my
build.xml file, I have <property name="lucene.jar" value="${lucene.v1}"/>.
This means that to change the version, I just have to go into the build file
and point to the next version and it is dependent upon the project
developers to choose which version of a file to use for their project
without worrying about all of the other projects.
The problem that I have is that this does not work for the System level
files like JUnit.
Chris Erskine
EDS Consulting Services
F5-EDS-001
2424 Garden of the Gods Rd
Colorado Springs, CO 80919
Phone: 719-265-5962
> -----Original Message-----
> From: James Abley [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 05, 2005 2:02 AM
> To: Ant Users List
> Subject: RE: Ant should have an ext directory
>
> On Wed, 2005-01-05 at 04:50, Erskine, Chris wrote:
> > I do not think that we are saying to use Maven. I am asking for a way
> to
> > support different versions of third party jars from the same instance of
> > ant. Maven is being used as an example of one way to do it. I do not
> need
> > the auto-download functionality of Maven or the automatic repository. I
> > would like to see a way to define in the build file, the list of
> dependent
> > jars with versions or a relative path to the a needed jar file so I do
> not
> > have to update the functionality of 30 projects at one time to support
> the
> > update of a single support jar.
> >
> > Chris Erskine
> >
> > EDS Consulting Services
> > F5-EDS-001
> > 2424 Garden of the Gods Rd
> > Colorado Springs, CO 80919
> >
> > Phone: 719-265-5962
> >
>
> Have you read or got access to a copy of "Java Development with Ant"?
> That has a good section about handling versioned dependencies which
> might work for you.
>
> It involves having a strict directory structure, and using a few levels
> of indirection with properties to reference dependencies. This allows
> you to override and use different versions as well if you have a
> compelling need to retain the ability to use older versions.
>
> (poor ASCII diagram to illustrate:)
>
> lib
> |-lucene-version1
> |-lucene-version1.jar
> |
> |-lucene-version2
> |-lucene-version2.jar
>
> When you move to a new version, just update your lib.properties file
> that contains the version information, and you have updated all 30
> projects.
>
> I haven't encountered a situation that required such complexity myself,
> so I'm just talking on a theoretical basis(!), but others on the list
> should be able to comment on how well such an approach works.
>
> James
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
