On Sat, 23 Feb 2002, Jose Alberto Fernandez wrote: > > But for the existing tasks: People will not want to explicitly import > > <junit> when they had it on their system classpath and it worked like > > a charm so far. > > > > This is where autoloading comes into play. You do not have to say anything > in your buildfile. ANT will load each piece in the classloader we imagine is > best.
Exactly - for all 'old' tasks we'll just use the original mechanism. It would be nice ( and perfectly possible ) to also allow an explicit <junit> declaration, with a named loader, and that would make it work without junit.jar in lib/. ( and not only 'possible', but may work even with standard delegation ). If an 'old' antfile is used, the original behavior will remain in effect. If you explicitely declare <junit>'s loader, you'll get the extra feature of beeing able to place it in a different place ( and get more flexibility, support different versions, etc). > > Even worse, a build file that used a new feature like named > > classloaders wouldn't work in Ant 1.4.1, not talking about Ant 1.3 ;-) We had enough debate about maintaining 'bacward compatibility', even for trivial things like attribute names. Having new features work in older ant is (imho) impossible by definition, if it would work it'll not be a 'new' feature. If you use a new feature, it won't work in older versions - but if you stick with the original features it'll work with any ant. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
