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 Thu, 11 Oct 2001 18:37:47 GMT
From: "Peter Donald" <>

> > >
> > > 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 :-)
> Naah - I am talking about Extensions - they got renamed in jdk1.3 to 
> "Optional Packages" ;) However they don't have to be VM wide like old 
> extensions just define libraries that can be loaded and managed any way seend 
> fit. Currently the JVM does not do it magically for you though.

To make things clear, in JDK1.3 there are two types of Optional packages: INSTALLED optional
packages (what was called Extensions before) and DOWNLOAD optional packages which are the
jars declared in the ClassPath entry of another jar. Such packages are not installed permanently
but loaded relative to the location of the jar calling it every time is needed.

Now, I do not think this is done by the JVM itself, but it must be done by the ClassLoader.
And in JDK1.2 there are predefined public Classloaders that know how to do that. Take a look
at It provides a Classloader implementation that one can create with
the equivalent of a classpath.

> > 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.
> Sounds like the Optional Packages/Extensions mechanism to me ;)

Yes, but the DOWLOADED one. For that, all what is needed is to set ClassPath entry on the
manifest of the jar of the ant-library, and then put any additional jars in the correct location
relative to that library. You could even have different libraries using diferent versions
of optional packages.

I know that URLClassLoader and such are 1.2 stuff, but I which we could rearchitect AntClassLoader
as a sort of proxy and underneath use either URLClassLoader for 1.2 or something of our own
in the case of 1.1. That would make JDK1.2+ installations to have the power of 1.2 available
to them, even if in 1.1 not everything is as rosy.

Jose Alberto

View raw message