Thanks!
Based on the feedback I got so far from Peter and Conor, I'll leave the default behavior unchanged ( i.e. different class loaders ).
+1
I'll also change the name of the attribute to 'loaderId' - and make sure this would work with a
<loader> type.
+1
Conor - I'm not sure we should add the <loader> type.
Let me know if you think it's required, it's quite easy to implement.
I like this approach but I think perhaps we should add that in 1.6 (MAIN).
Also for Conor - I really want to keep the magic property
for backward compatibility ( so a build.xml for 1.5 can be used with 1.4 ).
+1
There is a section in the docs where some of the magic properties are discussed - please document it there.
Just FYI, in the past we have had a situation where a task could be compiled under 1.3 and 1.4 OK, but if compiled under 1.4 it would not work under 1.3. The other way was OK (compiling under 1.3 and deploying under 1.4).
In this particular case, when compiled under 1.4, the resulting task class file would have references to ProjectComponent (even though there were no source references). Since this class did not exist in 1.3 it would fail.
Anyway my point is that forward compatability is harder to achieve than it looks. If you are going to distribute a binary version of this task it may be necessary to compile under 1.4 rather than 1.5. You'll have to test it out, I guess.
After I commit the patch I'll update the docs for taskdef/typedef - if you want I can only include
the new attribute and leave the magic property undocumented.
Everything should be documented, IMHO.
Conor
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
