ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: We need to stop the lies
Date Thu, 21 Feb 2002 16:29:49 GMT
On 21 Feb 2002, Stefan Bodewig wrote:

> > -how we autoload stuff in the lib dir
> > -why JRE ext directories are trouble
> > -why you cant add stuff later on and have parent stuff find it
> I'll add it to the FAQ and link it from the manual.
> How does that sound?

Sounds great ! It would be a good jakarta-wide resource, the
exact same problem happens for people using webapps for example.

> >> What do people think of breaking optional.jar into several pieces
> >> cut along the dependencies, optional-junit.jar, optional-trax.jar
> >> and so on.
> >
> > I seem some value in this; but we should start by dropping
> > 'optional' as they are less optional now; give them names like
> > ant-tasks-trax ant-tasks-junit.

+1, great idea.

What I don't like is the fact that we load optional.jar and what's inside
in the 'parent' class loader. 

I liked very much the idea of using named loaders, and a model similar
with what tomcat is using ( either version, but 3.3 in particular :-).
The 'common' loader in tomcat is used mainly for classes that _must_
be in the system loader ( for example because they are broken and
don't support the context class loader ), and for APIs that we want
shared by all webapps.

The webapp loader corresponds to a 'named' loader in ant, and it'll
include all the jars needed in the webapplication ( with more 
flexibility in ant, because you can emulate multiple webapps
by using multiple named loaders ). As we know from tomcat(s), that
works in most cases ( and in time more will work, as people start
using Class.forName() or the context class loader ). 

If we write such a document, it would be very good to sugest the 
same use as for a servlet container - with the system loader
containing minimal stuff and separate loaders for each unit. That 
would help both ant users but also servlet users.

> > What if we suddenly discover that some task now needs an extra jar
> > (like httpclient)?
> Somebody will have to take care of it.

The named loader proposal could solve this ( but require the
user to explicitely declare the location of all the jars ). 


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

View raw message