You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Linas Jakucionis <li...@itdesign.ie> on 2003/03/12 15:12:24 UTC

multiple definion of taskdef loads the same libraries again?

Hi,

I am not really sure, but it seems to me, that multiple taskdef tries to redefine the task 
that is already defined and loads the same libraries again without releasing the 
memory that was used for old definition...

The situation I have is the following:
1. I have build1.xml which defines taskdef ejbdocklet
2. I have another build2.xml which has to use ejbdocklet task also, so I have taskdef 
ejbdocklet in this file also.
3. The problem is that I have to call build1.xml:
a) separately
b) a lot of times from inside build2.xml

If I have task definition of ejbdocklet inside of build2.xml only, I can call build1.xml from 
inside of build2.xml and everything works fine, but I cannot run  build1.xml separately.

If I have task definition of ejbdocklet in both files, build1.xml works fine, but when 
running it multiple times using <ant> from inside of build2.xml the ant crashes with 
either message:

Exception in thread "main"

or messages stating that Java ran out of memory... (Sorry, I cannot quote the exact 
message now)


Is there any possibility to tell ant not to define task with taskdef if the task has already 
been defined?

Do you have any suggestions about this?

--
Linas
Ireland

Re: multiple definion of taskdef loads the same libraries again?

Posted by Mike McNally <m5...@works.com>.
> Is there any possibility to tell ant not to define task with
> taskdef if the task has already been defined?

Try using the "loaderid" attribute with a consistent identifier
(just make up a name) in all your <taskdef> tags.  I think that
the Ant "Definer" code will construct  a fresh class loader for
your task each time you call <taskdef> if you don't explicitly
identify a class loader.  (I assume your task code is not on
the system classpath.)

--
[ you are my main foo ] Mike McNally -- m5@works.com