If you download
https://github.com/downloads/ggtools/GrandUI/grand-ui-0.7.2.tar.gz, unzip,
replace ant.jar and ant-launcher.jar with updated jars ... and then launch
the bat file on Windows with a 32 bit JRE, it will render a visual for you
(including extension points).
I was also working on something similar a short while back ... and simply
decided to use the depends attribute.
For example:
<extension-point name="-jar" depends="compile"/>
<target name="module.specific.jar" extensionOf="-jar"
depends="another.jar.target">
...
</target>
Parag Doke
Save paper, save trees. Do not print emails/documents unless absolutely
necessary.
On Sun, Apr 19, 2015 at 1:21 AM, Stefan Bodewig <bode...@apache.org> wrote:
> [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
>
>
