ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darrell DeBoer <>
Subject Re: cvs commit: jakarta-ant/proposal/myrmidon/src/java/org/apache/myrmidon/components/builder ant1convert.xsl
Date Fri, 22 Mar 2002 01:26:15 GMT
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.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message