Leo,
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.
Erik
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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
