ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Noel Gadreau <>
Subject RE: Platform independend classpath in build.xml?
Date Wed, 31 May 2000 00:13:59 GMT
I agree with you. I also have several classpath and I would like to be able
to use this task for any of them. Maybe this 'classpath' task could be
modified to be able to specify the name of the property you want to set.

For instance:
 <classpath inherit="true">

would modify CLASSPATH (or ${classpth} ?) and:

 <classpath name="build.classpath" inherit="true">

would modify the 'build.classpath' property that can be reused using

Moreover, I think the same problem will arise for other path (like for .DLL
or .so needed by some JNI classes for instance). How about defining a task
that is able to add path to a list in a crossplatform way, which would not
be limited just to CLASSPATH. This way, if you need to specify PATH (to find
a tool or something), we could use the same class.

What do you think ?


-----Original Message-----
From: Conor MacNeill []
Sent: Tuesday, May 30, 2000 5:08 PM
Subject: RE: Platform independend classpath in build.xml?

> -----Original Message-----
> From: []On Behalf Of
> burtonator
> Sent: Wednesday, 31 May 2000 7:38
> To:
> Subject: Re: Platform independend classpath in build.xml?
> What would be cool is a way to set the classpath in XML:
> <classpath inherit="true">
>     <entry>${LIBROOT}appframe.jar</entry>
> </classpath>
> And this would build the classpath as:
> $CLASSPATH;./lib/appframe.jar
> oooohhh...

My build files often do not have a single classpath. As an example, I
currently have

build.classpath			- compiling standard files
descriptorbuild.classpath	- for building weblogic deployment
testbuild.classpath		- for building JUnit test harness
weblogic.classpath		- for running weblogic.

None of these classpaths include the classes which are typically in the
classpath that is used to run ant.

I am a little wary of an approach which makes the classpath a sort of
singleton concept. The management of the CLASSPATH environment variable in
the shell is often a major pain for the same reason.

I do like the <entry> concept for building up classpaths though.


View raw message