ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject Re: Delayed task Class creation and <systemloader>
Date Mon, 09 Dec 2002 18:02:16 GMT
Stefan Bodewig wrote:

> On Fri, 06 Dec 2002, Costin Manolache <cmanolache@yahoo.com> wrote:
> 
>> There is one point where this doesn't work - antcall
>> will create all the tasks. I'll try to find a solution
>> for that later.
> 
> It has to at least create all tasks that have been loaded by a custom
> loader as we may lose that information for the child build otherwise.

<taskdef> works as before ( it adds the Class ). The change only
affects task loaded from ant.properties. 

What I'll try to do next is add getters to Definer ( to make it act
as a real bean ), and save the Definer itself. ( I tought about 
adding a new TaskDef class - but what's the point of duplicating when 
Definer has all we need ?)

Regardless of the actual implementation - if a project has a lot of
taskdef ( and that will be true as antlibs are implemented ) it is 
valuable to implement the same policy of instantiating only what 
is used.



>> Assuming the AntTaskTable doesn't get vetoed ( and doesn't
>> break anything )
> 
> I've seen you've reverted it.  What has been broken?

The test case for typedef.

I'm working on this.

The gump run seemed fine ( no error caused by the change as far as I can
see ). 
 
>> I would like to move ahead and merge the <systemloader> task from
>> [embed] into the main branch.
> 
> Sounds useful, IMHO.

After I'm done with the "Class.forName only for the tasks that are used"
I'll make a proposal for <systemloader>.

Costin



--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message