On Wed, 20 Mar 2002 14:42, Darrell DeBoer wrote: > I quickly tried this out - the tools.jar extension didn't seem to be loaded > when I renamed to ant1compat.jar.
does ant1compat.jar declare a dependency on the tools.jar? > Anyhow, we probably need a more general > solution to the problem of adding antlibs which depend on other antlibs. > An example would be if you extended a antlib with a new different task, and > wanted to be able to share datatype references between the new and existing > tasks. (You don't want to always force the original antlib to be a .jar, > and reside in the top-level classloader). Then we end up with same issues and inconsistencies that we have in the current ant codebase. It also makes it harder to be forward compatible as we have to worry about both the XML representation and the java API of all the classes in the jars. For instance if you have a look at some examples in the current codebase. Move extends from Copy. Last time I checked it was possible to have filtering moves (which seems counter to my thinking) and obviously counter to other peoples thinking as someone added in a move speed-up "fix" that didn't take into account filtering. Now look at some of the tasks that extend Zip. You can use attributes like destfile, zipfile, jarfile and warfile interchangeably and you can even have them all set on one task (with last one winning). There are heaps more similar problems that are a direct result of people extending tasks rather than creating reusable beans and reusing said beans. Where there is reuse to be had I would prefer that we refactor parts of tasks into reusable objects (like CommandLine and friends) and then reuse these objects. In which case we can place these reusable classes into a jar (or preferrably into the framework). When we absolutely have to reuse other tasks then we should use the proxy/model/configuration representation and pass that to the Executor to run the task. This makes evolution of ant in future much easier. > I don't think he way extensions currently work will work, because the > classes will be loaded separately for each antlib, so instances couldn't be > shared. It seems that we need a way to declare that Antlib-A "depends" on > antlib-B, so that antlib-A could be loaded in a ClassLoader that was a > child of the antlib-B's classLoader. Easy to do code-wise but I would prefer to avoid doing it all - and even if can't be avoided we should leave it to later. -- Cheers, Pete ------------------------------------------------------- To fight and conquer in all your battles is not supreme excellence; supreme excellence consists in breaking the enemy's resistance without fighting. - Sun Tzu, 300 B.C. ------------------------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
