ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@apache.org>
Subject Re: The difficulty of extending Ant with large Antlibs because...
Date Mon, 19 Mar 2007 12:37:39 GMT
Wascally Wabbit wrote:
> Hi all,
> 
> A bit of frustration...
> 
> I've just begun upgrading my antlibs to Ant 1.7 and I'm just blown over 
> by the number of changed assumptions that are now part of base classes 
> like Task and UnknownElement. It's just surprising coming from a 0.5 
> revision change. It's becoming harder and harder to upgrade with Ant for 
> large antlib collections (IMO) because of the lack of a clear lifecyle 
> structure for data types and tasks (and task containers and probably 
> AntLibDefinitions too).
> 
> Some examples:
> 
> + With Ant 1.7 the inability to execute the same task twice (even if 
> _you've written it do handle this_)...UE was altered and now this line 
> breaks (from lines 291:296). UE is one of the great mysteries of Ant for 
> a extension developer:
> 
>    // Finished executing the task, null it to allow
>    // GC do its job
>    // If this UE is used again, a new "realthing" will be made
>    realThing = null;
>    getWrapper().setProxy(null); //OUCH!OUCH!OUCH!
> 
> If Task.maybeConfigure is called subsequently it promptly throws a NPE 
> because it uses the proxy w/o checking for null.

file a bug, with examples, if this is breaking yo.

> 
> + With Ant 1.7 a complete reversal of the ordering of attribute 
> configuration relative to child configuration...it's not the switching 
> that's the fundamental problem (implementation details and all that) but 
> Ant lacks any sort of public lifecycle event that a Task or 
> TaskContainer implementation can consistently count on from release to 
> release. It's always an adventure...even between minor minor revisions. 
> It's even possible for a Task's "init()" method to be called multiple 
> times...
> 
> Perhaps there could be a clear "I'm configured" trigger or event or 
> callback or method or something before the task's execute method is called.

+1
> 
> + Perhaps DataTypes can also have the ability to know when they've been 
> completely configured (from Ant's perspective)? I guess this is more of 
> the same lack-of lifecycle transparency as is the case for Tasks. I 
> often use "quiet" tasks to get these features, but this is a 
> heavy-handed solution.

I actually think these are good points. In SmartFrog we have an explicit 
lifecyle of
  -constructor
  -sfDeploy() invoked: you are live, your peers have all been 
constructed, but may or not be deployed. Read in your configuration 
data, and set any values you can, to share with your peers. validate 
anything and throw an exception if something is wrong.
  -sfStart() invoked. All your peers are in the deployed state. Start 
your work in a new thread. This is roughtly equivalent to execute.
  -sfTerminate(). Wake up, time to die. Can happen any time after 
sfDeploy() was invoked...you may not have started if a peer failed to 
deploy.
  -sfPing() : hit you for your system health.

Elegant termination handling is, well messy. Like when you want to issue 
SQL commands to the DB on shutdown, but it was the database itself that 
triggered the shutdown [yes, I have been doing functional testing of 
mysql last week :). How do you test that a database got rolled back on 
termination?]

Now, not all of this applies to Ant because it has an inherently 
sequential workflow, at least, not until you get into <parallel> where 
life gets complex, fast.

-We may want to consider having a formal AntLifecycle interface that 
lifecycle things can use -though there is the risk that embedded uses of 
tasks wont use it.

-A method telling a datatype that it is configured would be 
handy...maybe all ProjectComponents have their componentDeployed() 
method called by default. The rationale for datatypes is what if the DT 
has some work to do, like download an artifact from a remote site. Once 
its been configured, you want it to start its work.

-A componentTerminated() method is useful to say "you are no longer 
needed, ever. Clean up. Because finalizers are a no-no, and execute(), 
well, it can retain some state, can't it?"

Thoughts? Maybe we can have a little BoF on this topic at ApacheCon in May?

-steve



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message