[SUMMARY] User Defined Types/Tasks Loading/Recongnition of Dynamic Elements

[Magesh Umasankar <um...@apache.org>]

Hi,
Let me try to summarize what's been discussed so
that we can move forward:

The patch to map User Defined types/tasks to classes 
before default ones gathered a +0 vote and pointers
towards its elegance.  But, the need to load the 
user defined mappings just before Ant starts parsing 
the build-file was accepted.  So, I withdraw this patch
and wait for the day when an acceptable solution makes 
its way in ;-)

The patch (minus the above patch, of course) to 
IntrospectionHelper that helps it recognize addXXX(XXX) 
methods where XXX is assignable from the class type of 
the element being added, gathered a +1 vote and what I 
interpret as general acceptance from others - the need 
for the method name also to be flexible has been pointed 
out.  Since this patch doesn't prevent the above from 
happening in the future, I think we should recognize 
this as a need but not necessarily stop moving forward 
with this patch.

So, may I go ahead and commit the second patch alone
(after removing the embedded first patch from it) or 
does anybody want to -1 it?  Last chance :-)

Cheers,
Magesh



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [SUMMARY] User Defined Types/Tasks Loading/Recongnition of Dynamic Elements

[Stefan Bodewig <bo...@apache.org>]

On Wed, 27 Nov 2002, Costin Manolache <cm...@yahoo.com> wrote:

> I think the real info about this is that redefining tasks/types
> explicitely should work, and needs to be fixed.

Agreed.

Stefan

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [SUMMARY] User Defined Types/Tasks Loading/Recongnition of Dynamic Elements

[Costin Manolache <cm...@yahoo.com>]

Magesh Umasankar wrote:

> Hi,
> Let me try to summarize what's been discussed so
> that we can move forward:
> 
> The patch to map User Defined types/tasks to classes
> before default ones gathered a +0 vote and pointers
> towards its elegance.  But, the need to load the
> user defined mappings just before Ant starts parsing
> the build-file was accepted.  So, I withdraw this patch
> and wait for the day when an acceptable solution makes
> its way in ;-)

I think the real info about this is that redefining tasks/types
explicitely should work, and needs to be fixed.

What needs to be fixed is the execution of taskdefs before the 
task class is created - and that can be resolved either by 
moving back to execute top-level stuff imediately, or by
postponing the task class creation until before execution
( as embed does ). I don't see any major problem with either
of those solutions - I think we only need to discuss them and
find what we can agree is the best solution.

I think we agreed that the current behavior is broken - and 
that any solution will involve some tradeoff.


A different story is to support a mechanism to load some tasks by 
default at startup ( a sort of global .ant-startup.xml ). I've seen this 
mentioned on ant-dev in the past, and I think it would be nice to have.
If you have this you can customize what tasks are redefined at startup
( and a lot more ).


Costin



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>