Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Received-SPF: softfail (nike.apache.org: transitioning domain of
 nicolas.lalevee@hibnet.org does not designate 216.86.168.183 as permitted
 sender)
MIME-Version: 1.0
Date: Thu, 17 Dec 2009 08:06:59 -0500
From: =?UTF-8?Q?Nicolas_Lalev=C3=A9e?= <nicolas.lalevee@hibnet.org>
To: Ant Developers List <dev@ant.apache.org>
Subject: Re: [POLL] target-groups
In-Reply-To: <874onqf0v0.fsf@v35516.1blu.de>
References: <873a3dycgk.fsf@v35516.1blu.de> <4B283D95.2010900@callenish.com>
 <874onqf0v0.fsf@v35516.1blu.de>
Message-ID: <4a0ac0aa0ffb2e57f69afd59d65d07c5@mail.mxes.net>
User-Agent: RoundCube Webmail/0.3-stable
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8

On Thu, 17 Dec 2009 09:42:11 +0100, Stefan Bodewig <bodewig@apache.org>
wrote:
> On 2009-12-16, Bruce Atherton <bruce@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.

As I see them, target groups are expected to be "hooked" by other targets,
then they should "shared" between several build files. IMHO they should be
used composition more than aggregation, import more than include, so it is
not an issue.

Nicolas


> 
>> 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-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org

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