On 2009-12-16, Bruce Atherton <br...@callenish.com> wrote:
> To me, only two of the options are seriously being discussed right now:
> 1) the current target-group codebase
> 2) moving the behaviour of target-group into all targets through a
> marker attribute
Nobody is more surprised by this then myself. Nicolas dug out the old
thread which lead to 2 but I had long forgotten about it.
> On first glance, changing target-group to a target with a marker
> attribute looks like a NOP, but this is not necessarily true. As you
> pointed out before, Stefan, targets are used in quite a lot of
> contexts and in some of those contexts (like import) things might get
> a bit confusing if we just substitute a the target-group concept in
> for a target.
This is what the current codebase does anyway (treating target-group
like targets in any context) - and its where EasyAnt differs, they apply
different rules to phases in imports.
So from the viewpoint of the current codebase the two options you have
highlighted are really not very different. That doesn't mean it has to
be that way.
> My question is whether we need to provide different behaviour under
> any circumstances between a target and what we now call a target-group
> (other than the obvious extension of dependencies).
IIRC the difference in EasyAnt boils down to not prefix the names of
phases when they get <included>, i.e. if you <include>
<project name="a">
<target-group name="b"/>
</project>
the target-group's name is "a.b" if you want to add your target to it
(from outside the included file). Using EasyAnt's phase it would be
"b".
I think EasyAnt's motivation is something like
<project name="top">
<include file="standard-javac-stuff.xml"/>
<include file="generate-sources.xml"/>
</project>
<project name="standard-javac-stuff">
<target-group name="ready-to-compile"/>
<target name="compile" depends="ready-to-compile">
<javac ....
</target>
</project>
<project name="generate-source">
<target name="generate"
group="I'd love to be part of ready-to-compile">
...
</target>
</target>
With Ant's current code base the target-group's name is
standard-javac-stuff.ready-to-compile. How would the generate target
know that, considering the as-attribute on <include> (not used here).
To make things worse, <include> re-writes group and depends attributes
to prefix them, so there is no way for the target to join the target
group at all, even if it knows the name.
To be properly self-contained generate-source.xml could have <include>ed
standard-javac-stuff, but then the target-group it had joined would be
different from the target-group used by the top-level build file.
Of course all the problems disappear if you use <import> instead of
<include> - and you get a different set of problems like overriding
targets by accident because they happen to share the same name.
> If they can be treated as completely equivalent I'd favour what I've
> labelled as option 2 above.
I agree. This meant there wouldn't be much use in the current
implementation.
> If there are circumstances where, for example, you couldn't add a
> dependency to a suitably marked target because of namespace issues or
> import issues or whatever, then I would vote for option 1 above, so as
> to make it clear to the user that there are considerations that need
> to be made when using the target-group construct.
Which meant changing the current codebase, which I'm totally fine with.
All we need is to agree on the semantics before we modify the
implementation - and probably before we try to find suitable names.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
