On Mon, 15 Sep 2003, peter reilly <[EMAIL PROTECTED]> 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.
>> 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.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
