ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Conor MacNeill <>
Subject Re: Optional tasks
Date Wed, 10 Oct 2001 14:05:28 GMT
Here are my random collection of thoughts on this interesting discussion :-)

Peter Donald wrote:

> On Wed, 10 Oct 2001 19:59, Jose Alberto Fernandez wrote:
>>Why is our shell/batch script putting things in the CLASPATH?
> why do we use batch scripts?

IMHO, scripts started out as a convenience. Even if all the script did 
was to run

java -jar $ANT_HOME/lib/ant.jar

I think we would still use them. Over time much more has been heaped 
into them, but they remain, primarily, convenience launchers.

>>Following this line, the correct thing to do would be to specify all the
>>jar dependencies for ANT core in ant.jar itself and let the JVM made up the
>>classpath. Hence we would be able to just do "java -jar $HOME/bin/ant.jar
>>$@" or equivalent.
> The JVM does not implement that. Go read the Optional Package spec - it is up 
> to developer to do it. The new servlet and EJB APIs require container 
> implement it IIRC so we should see more vendors using it. 

I'm not quite sure what you mean here, Peter. The VM does use the 
ClassPath entries in the manifest without any developer intervention. 
Also, I presume you are taking about download optional packages as you 
don't seem to like installed optional packages aka extensions :-)

The Classpath: entries in the manifests of download optional packages 
are, however, really only practical for relative dependencies. In many 
cases tasks will have dependencies on other classes, the location of 
which can not be known when the jar is created. I have been thinking 
about how these dependencies can be resolved. In Ant 1.x, it is 
primarily the classpath that is used to resolve these dependencies. For 
a task to be instantiable, the required classes have to be loadable by 
the JVM. It is here, however, that we run into classloader problems 
since when these classes are on the classpath, they are also in the 
system classloader space and, as we know, this can cause problems.

What I think is needed is mechanism where these classes upon which a 
task depends are loaded through the tasklib's classloader but whose 
location is not known when the tasklib jar is put together.

We probably also need to consider the classloader hierarchy which is 
going to operate under Ant2. I'm sort of expecting a situation where 
Ant2 would be run with an empty classpath (enforced in the pesky 
scripts). The root classloader would contain the shared class resources 
- mostly interfaces that allow the core to talk to tasks - such as the 
task interface, task context etc. The core and tasks would have separate 
loaders so nothing else would be shared. This would allow tasks to have 
their own XML parsers, for example, without bumping into the parser 
being used by the core. OTOH, some tasklibs may want to have access to 
these sorts of common resources, so we may allow a tasklib to specify 
where in the classloader hierarchy its classloader lives. In any case 
the task would not have access to the bulk of the core's classes.

>>In any case, in ANT, any additional jars should be declared in the
>>classpath of the tasks (which are not core) that need it.
> today - yes. Tomorrow I don't see any reason for that. The type library can 
> declare it's own dependencies and leave the container to determine the best 
> way to satisfy the dependencies. I don't see a good reason why the user 
> should have to deal with semi-difficuly problems (like ClassPath management) 
> when it can be automated.


> I largely like it but I am comfortable with XML. As a few people (Conor?) 
> pointed out it is less intuitive and much more complex if you are forced to 
> use namespaces for tasks (aswell as for aspects, and perhaps for inter build 
> file referencing and ...).

I think namespace qualifiers on all task references is probably a little 
clumsy and I prefer the java import style, with the potential addition 
of aliasing, to declare a name in the flat task namespace.


View raw message