ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject Re: private to protected and extensibility of Ant
Date Sat, 14 Sep 2002 19:23:00 GMT

While we strive to keep things from breaking, we're mostly doing that 
from the perspective of Ant "users", not folks that are extending Ant's 
API, which is (arguably?) not made to be extended in some of the ways 
that you obviously are.

While I cannot comment on the exact details of your dilemma without 
trudging through the code in detail, I will add that Ant's codebase is 
constantly available for all to use at any time.  If you rely on Ant's 
API so tightly, then please take the opportunity to pull the HEAD 
version of Ant from CVS every so often and check it against your stuff 
and let us know *before* a release if we've broken anything.  Anything 
that has changed since the last release can be reverted or changed with 
very little concern, but once we make an official binary release we have 
obligations to adhere to the released API as much as possible.

As for private/final - I differ a bit on this.  I think as open-source 
is developed, it should be locked down tightly at first *until* a need 
is seen that requires it to be opened up.  Protected getters make sense, 
but classes that are not originally intended to be subclasses should be 
final, and so on.  Extensibility can evolve from a locked down state, 
but once the gates are open, it cannot tighten back up.

For a good example project on it evolving in this manner, check out 
Lucene - its got a lot of final classes and private stuff.  Its opening 
up things on an as-needed basis, but carefully thought out only when 
real use cases are presented that require it.


Leo Sutic wrote:
> All,
> I recently upgraded to Ant 1.5 and saw some of my code break.
> No big deal that, but I'd like to 
>  + offer some feedback on Ant
>  + make one suggestion
> Ant is good, otherwise I wouldn't use it. Now for the bad part.
>  + Ant is difficult to extend.
>    Take the Ant task for example. I have a subclass (now broken)
>    that allows the addition of a subclass of Property to the
>    Ant task. The Property subclass works just like its superclass,
>    but it is lazily evaluated. I won't dwell on it, but basically
>    I have a subclass of Ant, that would like to add a subclass of
>    Property to the invoked project.
>    In Ant 1.4, I could do this:
>    public LazyProperty createLazyProperty() {
>      if (p1 == null) {
>             init();
>         }
>         LazyProperty p= (LazyProperty) p1.createTask ("lazyproperty");
>         if (p == null) {
>             p1.addTaskDefinition ("lazyproperty", LazyProperty.class);
>             p= (LazyProperty)p1.createTask("lazyproperty");
>         }
>         p.setUserProperty (true);
>         properties.addElement (p);
>         return p;
>       }
>     }
>     In Ant 1.5, init() and properties are private to Ant.
>     A similar situation occurred when I wanted the SQLExec task to
>     output data in XML format. I ended up simply copying the SQLExec
> task
>     (not subclassing) and added my functionality to the copy. Much
> easier.
>     So I would like to, well, *raise awareness*, that you shouldn't be 
>     over-eager with the private and final keywords, because it severely
>     cripples the extensibility of Ant itself.
> Suggestion:
>     In all simplicity. Add a 
>        protected void addProperty(Property property) {
>         if (newProject == null) {
>             reinit();
>         }
>         properties.addElement(p);
>        }
>     method to the Ant task. I would like to have protected accessors
>     for all fields, but for now, this is enough.
> /LS
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

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

View raw message