ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject Re: Optional tasks
Date Tue, 16 Oct 2001 11:28:03 GMT
From: "Bill Burton" <>
> Peter Donald wrote:
> > What they used to call Extensions are now called Optional Packages. They seem
> > to like renaming stuff. I am not sure where you got that blurb from but the
> > jdk1.3 stuff has it documented. Specifically I am looking at using stuff that
> > places data in manifest like
> > 
> > Extensions-required: junit
> > junit-Specification-Name: org.junit
> > junit-Specification-Version: 3.7
> AFAIK, that stuff only applies to applets or containers implementing JNLP
> such as Java Web Start.  

Well, I think it is fair to say that this is up to the ClassLoader to do something with this
In my opinion a good start would be to retrofit AntClassLoader to at least understant "Class-Path".
That should be quite simple to do, IMHO. Ant would be a first step on finding a path thru
the woods,
with respect to library reference resolution.

> > > > However in reality you would usually define a OS environment variable
> > > > extend it. Probably something like
> > > >
> > > > export
> > > > ANT_LIB_PATH=~/ant-ext/lib:/opt/some-local-tool:/usr/local/another/local/
> > > >tool
> > > >
> > > > or whatever.
> No.  Environment variables aren't needed!  A command line option or
> property should be used instead:
>     -L ~/ant-ext/lib:/opt/some-local-tool:/usr/local/another/local/

Unless we think that people are goint to type all that every time they invoke ANT, the reality
is that
at the end it would mean having an environment variable that is used in the script. This is
saying that we do not need CLASSPATH because you can do "java -classpath XYZ:ZYX ...".

> > > So we are just moving or incrementing the issue of managing the CLASSPATH
> > > to also managing some other ANT_LIB_PATH. Not too much of an improvement.
> > > My wish would be for ANT not requiring any special manipulation of
> > > CLASSPATH nor any aditional environment variables.
> > 
> > Theres not much you can do about that. Didn't you punt it to the build file
> > writer? Most people will ever have to deal with this because there will be
> > reasonable default. I haven't come across a project yet where the reasonable
> > defaults would not suffice.
> Need to first think of Ant as a reusable container that can be
> instantiated and configured within IDE's and other tools.  Then determine
> a simple command line invocation strategy using a combination of command
> line parameters and possibly a property file with sufficient information
> to bootstrap the runtime.  Environment variables are of no use or help in
> this scenario and only increase the complexity of scripts used to invoke
> the runtime.  The only exceptions to this might be JAVA_HOME and ANT_HOME
> which the wrapper scripts could continue to use.
> At the bare minimum, all functionality currently in scripts to set or
> modify the CLASSPATH needs to be moved into Java.  The end result is one
> could invoke Ant with something as simple as:
>     java -jar /usr/local/ant/lib/ant.jar -home /usr/local/ant -java_home
> /usr/j2se

I gree with you on this one.

> This would imply loading all jars in Ant's common/lib (like Tomcat) and
> adding tools.jar to the classpath plus loading all tasks, etc. from Ant's
> ext directory.  The path for the latter could be supplemented or
> overridden with an -L option as described previously.

The main problem we have today, IMO, is that to achieve this we need to manage
all ClassLoading using our own ClassLoaders for which we can control the path
on our own Java code. But that means some heavy rearchitecting of the way the code
is executed today. We would need that the JVM ClassLoader only loads a very very small
part of the code that it is only used to start the real code thru our own classloaders.

It would be an interesting disecting job :-)

Jose Alberto

View raw message