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.
Agreed.
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.
Conor
