ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Classloaders and optional.jar (was Re: My itches for 1.6)
Date Tue, 16 Jul 2002 14:57:19 GMT
On 16 Jul 2002, Stefan Bodewig wrote:

> > IMHO the biggest problem at this moment is the fact that
> > optional.jar is loaded in the system class loader.
> We probably all agree on this. 8-) We could dramatically improve the
> situation by a very simple step though, splitting up optional.jar
> along its dependencies.

That would be great - it could also be a first step in modularising 
ant task library. I think we should also discuss namespace issues
in this context - but one step at a time.

However, as I mentioned in one of the many mails, I would also like
a solution that can be aplied to ant1.5. 

ProjectHelper hook allow someone to install a 1.5+ 'extension' that
provide parsing. This can be used to enable some other things, like
the reverse loader or the <import>.

I think it would be very valuable to have all the new stuff that we're
going to put into 1.6 tried out - we have a very long release cycle
and projects can't use the cvs head.

Having small groups of tasks available as a separate 'library' 
that works in 1.5+, and keeping them as a separate entity ( like
 a commons sub-project ) would have the most benefit IMHO. 

If everyone agrees that smaller libs are the way to go - we can
start eventually using a different namespace and releasing the 
components one by one ( without conflicts with the old ones - 
so Peter can't complain too much :-)

> Combine this with a new class loader scheme for antlibs only.
> Further, make it possible to use the now split up parts of
> optional.jar as antlibs, if the user asks for it - but keep them on
> the system classpath by default.  Finally, provide all new tasks as
> antlibs.

We can keep the old libs in the system classpath, and release
tasks in a new package ( org.apache.ant.something ) - as antlibs.
This will insure maximum backward compatibility ( i.e. 100% ), 
and will give users a very easy migration path and imediate 
access to the new tasks.

Instead of waiting until 1.6 to get user feedback on import, we can
get it now - by releasing first an aplha, beta and then freezing
the <import> semantics ( again, the current model is to release the
whole 1.6 - and get feedback and freezing few dozens new tasks ). 

> > There are 2 solutions for that - one is to use a tomcat-like loader
> > hierarchy. The other is to do a small hack
> +1 on a non-hacky clean hierarchy.

I agree - if we can release a junit antlib there is no need for the 

I'll still try to make the hack work - as a short-term solution
for 1.5 users ( because in the process I want more testing on
the sax2 processing ).


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message