[pretty impressive build setup, kudos]
On 2015-04-14, Stranzenbach, Ralf wrote:
> <target name="clean" depends="-clean" />
> <extension-point name="-clean" />
> <target name="recompile" depends="-recompile" />
> <extension-point name="-recompile" depends="-clean, -compile" />
...
> <target name="recompile-clean" extensionOf="-clean" if="is.Recompile" >
> <echo>Additional behaviour for recompile</echo>
> </target>
> <target name="-recompile-switch">
> <property name="is.Recompile" value="true" />
> </target>
Before I go into Java options, none of them nice, couldn't you add a
dependency to "-clean" that was an (empty) extensionPoint itself and
make "-recompile-switch" and extension of that extensionPoint?
> Now my question(s):
> ================
> Are there any ways to define the order of execution to guarantee an
> optional task just like "-recompile-switch" to execute at the right
> moment?
Maybe, but not in a nice way.
After figuring out the dependency graph Ant prepares an array of target
names and passes them to the registered Executor instance - by default
org.apache.ant.helpers.DefaultExecutor. You could replace it with an
executor of your own (by setting the property ant.executor.class when
starting Ant), inject your switch target and delegate to
DefaultExecutor. Of course this would be a one-off solutions, but at
least you don't need the overhead of antcall.
The actual graph building happens in Project's topoSort method
\begin{digression}
This actually answers your second question
> Is there any way using the Java API to the ANT core to inspect the
> execution graph?
project.topoSort(targetsInvokedOnCommandLine, project.getTargets(), false)
should work.
\end{digression}
Unfortunately we are making it pretty difficult to inject a Project
implementation of your own, it is hard coded in Ant's Main. This means
if you simply wanted to override topoSort you'd not only need subclass
of Project but your own implementation of AntMain as well.
> Unfortunately it is impossible to manipulate the execution graph at
> runtime, conditionally <import>ing different extesions.
I don't think this is completely true. <import> is a task itself, it
uses some support in Ant's ProjectHelper but you can write a task of
your own that performs the same actions. Whether you could
conditionally imprt different extensions depends on what you'd want
to base your decision on. It would work for anything that is fixed at the
point in time when Ant parses the build file. This includes properties,
but unfortunately it does not include the targets specified at the
command line (they are fixed, but there is no way to know them in a top
level task).
If the aditional dependency extensionPoint doesn't work, the most clean
solution would be a custom Project and AntMain - but it would also imply
quite a bit of work.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
For additional commands, e-mail: user-h...@ant.apache.org
