ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From peter reilly <>
Subject Re: [VOTE]: Getting 1.6 out the door
Date Wed, 17 Sep 2003 10:42:12 GMT
On Wednesday 17 September 2003 10:51, Stefan Bodewig wrote:
> On Mon, 15 Sep 2003, peter reilly <> wrote:
> >> In particular, I'm not too fond of the completely undocumented
> >> <classloader> task.
> >
> > It would be nice to get this fixed.
> I rather opposed to the idea of adding stuff to a class loader that
> has been used before - especially for the system classloader.  I'm not
> sure whether there is something that could be fixed.
> <classloader> gets you into a position where you load the same class
> twice.
> <taskdef resource="...">
>   <classpath>
>     <pathelement location="my-tasks.jar"/>
>   </classpath>
> </taskdef>
> and later you go and add my-tasks.jar to the system class loader via
> <classloader>.   Suddenly the class is available in the same
> classloader twice (the one that loaded the tasks in <taskdef>) and
> some of them have already been loaded - and not from the system
> classloader that will be used in subsequent attempts.


> I'd rather stay away from this completely.

For 1.6 we should.

> >> Peter, we will have to get this "why is <antlib> a taskcontainer"
> >> question sorted out soon ;-)
> >
> > Like I said before, it is nice that one can use definers defined
> > in the same antlib.xml.
> I agree with this.
> > Having <antlib/> as a taskcontainer also allows arbitarary tasks
> > to be run, which may be an good or bad thing......
> I tend to see this as a bad thing.  IMHO <antlib> should declare new
> elements, it should not send mails to the creator of the classes, scp
> the /etc/passwd file around or just simply compile stuff.
> It's not because it can be abused (even if my examples make it look
> like that was my concern) - I want to see the concerns separated
> properly.  <antlib>'s job is not to compile tasks, that's what we use
> <javac> for.  All it has to do is declaring element name to class
> mappings.  Defining definers also creates such a new mapping.

I have done some more investigation.
The reason why using defined definitions do not work unless
antlib is an taskcontainer is UnknownElement#handleChildren. This
loops tru the all unknown elements and checks if the parent can
handle them. After handleChildren is called, the maybeConfigure
is called which invokes the defines if addConfigured(AntlibInterface)
is used in antLib.

A fix could be to keep antlib being a task container, but check
if the type of task/type is a AntlibInterface, and if not, to
reject the task/type.


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

View raw message