ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: cvs commit: jakarta-ant/proposal/myrmidon/src/java/org/apache/myrmidon/components/builder ant1convert.xsl
Date Thu, 21 Mar 2002 23:36:40 GMT
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.



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:   <>
For additional commands, e-mail: <>

View raw message