On Fri, 22 Mar 2002 09:36, Peter Donald wrote: > 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? >
Yep. There was no change from the working ant1compat.atl, except it was renamed to ant1compat.jar. But honestly, I didn't spend any time investigating further - will do. > > 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. Fair enough. I wasn't thinking of extending Tasks, but just sharing datatype instances. I was hoping to package ant1compat-optional.atl separately from ant1compat.atl (and maybe break it down into smaller antlibs) and be able to share Ant1 Path/FileSet instances as references, without making Ant1Compat a .jar file. Another example. Image JUnit releases their .atl antlib, and then I want to write a new "TestDoc" Task that makes use of their "TestDefinition" datatype, so I can declare a set of tests with a <testdefinition id="?"> element, and then run it through both <junit> and <testdoc>. One way, of course, would be to package up the "shareable" parts and put them in a .jar file, loaded in the primary classloader. And I guess that JUnit could release a .jar containing datatypes/roles, separate from the .atl containing Tasks. But is there a way we can implement the handling Optional Packages so that if LibChild.atl declares a dependency on LibParent.atl, we don't load up the LibParent.atl separately for LibChild.atl, but provide a multi-parent classloader that includes the LibParent classloader as on of it's parents. Sorry if this doesn't make sense - I'm not 100% on the intricacies of classloading (make that 25%, but currently learning). In fact I had not heard of the concept of "multi-parent" classloaders until recently. I assume that such a classloader still has one true parent (as in ClassLoader.getParent()), but has a list of other classloaders to delegate to in it's ClassLoader.findClass() method. If this is possible, it sounds like it might be a good potential solution, which avoids having to create a complex hierarchical tree of classloaders to handle dependencies, but also avoids having to push everything shared into a single, top-level classloader. I guess the only problem is where a dependency uses statics, and each user of that dependency expects a private copy. Anyway, enough ramblings. ciao Daz -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
