Bug 40643 - Allow dependency injection on child tasks
Summary: Allow dependency injection on child tasks
Status: NEW
Alias: None
Product: Ant
Classification: Unclassified
Component: Core (show other bugs)
Version: 1.7.0Beta2
Hardware: Other other
: P2 enhancement (vote)
Target Milestone: ---
Assignee: Ant Notifications List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-09-29 16:16 UTC by Keith D Gregory
Modified: 2012-05-28 11:09 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Keith D Gregory 2006-09-29 16:16:45 UTC
Add the following method to the Task class, with no-op default behavior:

    /**
     *  Allows parent tasks to inject dependencies into their children.
     *  This method is typically called by the parent in <code>addTask()
     *  </code>. Children may accept or reject the dependency, and do
     *  not have to notify the parent.
     *
     *  @param  parent  Identifies the parent task.
     *  @param  data    Arbitrary dependency data. The child must know
     *                  how to process this data. May be <code>null</code>.
     */
    public void injectDependency(Task parent, Object data)

The implementation on UnknownElement would queue all (parent,data) tuples, then
play those back to the actual child in configure()
Comment 1 Matt Benson 2006-10-13 12:55:26 UTC
could be interesting, but personally I'd need more detail, maybe a use case and
an example, to form a real opinion here.
Comment 2 Keith D Gregory 2006-10-16 16:22:51 UTC
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.