ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: [VOTE]: Getting 1.6 out the door
Date Wed, 17 Sep 2003 09:51:13 GMT
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

<taskdef resource="...">
    <pathelement location="my-tasks.jar"/>

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.

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


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

View raw message