ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 40643] - Allow dependency injection on child tasks
Date Mon, 16 Oct 2006 23:22:52 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=40643>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40643





------- Additional Comments From kgregory@healthmarketscience.com  2006-10-16 16:22 -------
The current design of Ant assumes that child tasks are independent of their
parent: Ant calls the task's no-arg constructor, then adds it to the parent. It
does not tell the child about the parent (as best I can tell, looking closely at
the 1.6.5 codebase and skimming 1.7.0).

There are many situations where this knowledge would be useful, allowing the
parent to set up a context in which the child operations. For example, we have a
set of Ant tasks that interact with an app-server. They're contained within a
task that establishes the connection to the server, and provides context for the
children.

Similarly, one could envision a deployment target that executes multiple SQL
statements against a server. While you could create the connection anew for each
child task, a better approach (in my opinion) would look like the following:

<sqlConnect url="jdbc:..." user="${db.username} pass="${db.password}>
   <sqlUpdate sql="insert into ${db.schema}.MY_TABLE ...">

At present, it is possible to do this, but there are limitations.

One approach is to use nested elements, and have the parent task provide a
factory method for its children. The primary limitation to that approach is that
the children will be configured at the same time as the parent, meaning that you
have to deal with all properties as strings, and perform all conversions
yourself (because the properties may not have been set at the time of
configuration, particularly if they're set by sibling tasks).

Another approach is to use the "normal" method of task creation, and have the
parent reconfigure its children before executing them. This is somewhat of a
hack, as the parent has to dig into the UnknownElement to find the real task. It
also didn't work prior to bugfix #40641, because the UnknownElement would ignore
the parent's actions, and reconfigure the task prior to execution.

I am hoping to be able to free up the time to write a patch and some example
scripts.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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


Mime
View raw message