----- Original Message ----- From: "Dominique Devienne" <[EMAIL PROTECTED]>
I don't understand why you need to load custom tasks/types before the Core tasks/types. The current mechanism for loading them seems OK to me
(awaiting
<antlib> for a better mechanism though).
<antlib> or <rantlib>? ;-(
The problem as has been discussed before is that the mechanism that currently exists to initialize default tasks checks to see if users are using 'known' nested elements. Let us take <condition> for example:
<condition property="filename" value="Windows NT"> <os name="Windows NT"/> </condition>
In the end, therefore, I think your change is solving the problem in the wrong place :-)
I think we really want to move to a dynamic model where we separate parsing from configuration. All Ant2 propsals do this and I think it is effective. I know this is a backward compatability issue (actually I changed the code once to use only UnknownElement and did a Gump run without problems but it may be a problem for other builds). What I wonder is whether we can provide a switch to select between the current behaviour (i.e. parse/config at the same time (mostly)) and a fully dynamic model.
Supporting the two behaviours may be cumbersome but it may give us a way forward to introduce new features (i.e. polymorphism) which depend on the dynamic model. The switch could be defined in the build file (introduce a version attribute to the project, for example). These features could be compelling reasons to upgrade to the new behaviour
Conor
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
