You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Stefan Bodewig <bo...@apache.org> on 2009/12/14 13:19:55 UTC
[POLL] target-groups
before we get carried away with naming discussions ...
Currently I don't feel there is consensus of what we'd like to see with
target-group (if anything at all). The options I see are
* have some sort of composite of targets that other targets can add
themselves to
* have some special construct that has a depends list similar to
target. targets can depend on such a construct and add themselves
to the depends list (the current code base).
* allow targets to add themselves to the depends lists of any other
target
* allow targets to add themselves to the depends lists of targets that
in some way mark themselves as being open for such extensions
* no target-group like construct at all
* something completely different?
What is your preference?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [POLL] target-groups
Posted by Antoine Levy Lambert <an...@gmx.de>.
Hi,
I am fine with the current code base. In fact, I never experienced the
need for target-group(s), but I can imagine myself using them if they
are available.
Regards,
Antoine
Stefan Bodewig wrote:
> before we get carried away with naming discussions ...
>
> Currently I don't feel there is consensus of what we'd like to see with
> target-group (if anything at all). The options I see are
>
> * have some sort of composite of targets that other targets can add
> themselves to
>
> * have some special construct that has a depends list similar to
> target. targets can depend on such a construct and add themselves
> to the depends list (the current code base).
>
> * allow targets to add themselves to the depends lists of any other
> target
>
> * allow targets to add themselves to the depends lists of targets that
> in some way mark themselves as being open for such extensions
>
> * no target-group like construct at all
>
> * something completely different?
>
> What is your preference?
>
> 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
Re: [POLL] target-groups
Posted by Dominique Devienne <dd...@gmail.com>.
On Mon, Dec 14, 2009 at 6:19 AM, Stefan Bodewig <bo...@apache.org> wrote:
> * have some special construct that has a depends list similar to
> target. targets can depend on such a construct and add themselves
> to the depends list (the current code base).
+1, modulo the terminology.
> * allow targets to add themselves to the depends lists of targets that
> in some way mark themselves as being open for such extensions
+1, not much different from my other +1 above.
> * no target-group like construct at all
the functionality would have been useful to me in the past when
building reusable and extensible build scripts, so I do believe it has
value. Finding the right terminology is the only pb here IMHO. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [POLL] target-groups
Posted by Nicolas Lalevée <ni...@hibnet.org>.
On Mon, 14 Dec 2009 13:19:55 +0100, Stefan Bodewig <bo...@apache.org>
wrote:
> before we get carried away with naming discussions ...
>
> Currently I don't feel there is consensus of what we'd like to see with
> target-group (if anything at all). The options I see are
>
> * have some sort of composite of targets that other targets can add
> themselves to
>
> * have some special construct that has a depends list similar to
> target. targets can depend on such a construct and add themselves
> to the depends list (the current code base).
>
> * allow targets to add themselves to the depends lists of any other
> target
As I explained in the other thread, I finally think this is the simpler
solution.
> * allow targets to add themselves to the depends lists of targets that
> in some way mark themselves as being open for such extensions
I tend to prefer to keep it open by default, but I won't make any veto
against it. For instance I have not the experience described by Bruce
about finding "backwards chaining [being an] often (usually) surprising
behaviour to the first time user, but once learned quickly becom[ing]
second nature."
Nicolas
> * no target-group like construct at all
>
> * something completely different?
>
> What is your preference?
>
> 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
Re: [POLL] target-groups
Posted by Nicolas Lalevée <ni...@hibnet.org>.
On Thu, 17 Dec 2009 09:42:11 +0100, Stefan Bodewig <bo...@apache.org>
wrote:
> 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.
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
Re: [POLL] target-groups
Posted by Stefan Bodewig <bo...@apache.org>.
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-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [POLL] target-groups
Posted by Stefan Bodewig <bo...@apache.org>.
On 2009-12-16, Bruce Atherton <br...@callenish.com> wrote:
> Sorry if the previous thread was hijacked by naming issues, but I'm
> not sure I'm ready to vote in a poll yet.
That's why it only is a poll and not a vote 8-)
To be honest I was hoping to get away from the naming issue and to a
discussion of the feature itself - looks as if I had been successfull.
So far I don't feel that we are all on the same page and would feel
uncomfortable going forward with the release process before we took the
time to resolve the issue.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [POLL] target-groups
Posted by Nicolas Lalevée <ni...@hibnet.org>.
On Tue, 15 Dec 2009 17:53:25 -0800, Bruce Atherton <br...@callenish.com>
wrote:
> Sorry if the previous thread was hijacked by naming issues, but I'm not
> sure I'm ready to vote in a poll yet.
>
> 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
>
> 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.
>
> 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). If they can be
> treated as completely equivalent I'd favour what I've labelled as option
> 2 above. 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.
>
> Can anyone give a concrete example where there would be a problem
> treating a target-group as if it were a target?
Nitpicking: I would ask the question the other way: is there an issue to
make targets opened like target groups ?
For my part I don't see any. But as already wrote I have not the
experience you described about finding "backwards chaining [being an] often
(usually) surprising behaviour to the first time user, but once learned
quickly becom[ing] second nature." I got directly to the second step (maybe
because I learned Ant by reading build files wrote by Stéphane ;))
Nicolas
>
> Stefan Bodewig wrote:
>> before we get carried away with naming discussions ...
>>
>> Currently I don't feel there is consensus of what we'd like to see with
>> target-group (if anything at all). The options I see are
>>
>> * have some sort of composite of targets that other targets can add
>> themselves to
>>
>> * have some special construct that has a depends list similar to
>> target. targets can depend on such a construct and add themselves
>> to the depends list (the current code base).
>>
>> * allow targets to add themselves to the depends lists of any other
>> target
>>
>> * allow targets to add themselves to the depends lists of targets
that
>> in some way mark themselves as being open for such extensions
>>
>> * no target-group like construct at all
>>
>> * something completely different?
>>
>> What is your preference?
>>
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [POLL] target-groups
Posted by Antoine Levy Lambert <an...@gmx.de>.
Dominique Devienne wrote:
> On Tue, Dec 15, 2009 at 7:53 PM, Bruce Atherton <br...@callenish.com> wrote:
>
>> Can anyone give a concrete example where there would be a problem treating a
>> target-group as if it were a target?
>>
>
> Can't. But my thinking is that we should ere on the conservative side
> when we introduce such a feature, and that it's easier to open it up
> later on to all targets with no BC issues, than closing it up because
> real world issues crop up, with BC issues. I really do believe that
> having target-group (or whatever the final name) purely abstract
> encourages better reusable build design by forcing to think in terms
> of the build's "public API" that provides clean "hooks" for reusable
> implementation-specific pieces to tack on. But as usual I seem to be
> in the minority and I certainly won't be casting any blocking votes on
> the matter. --DD
>
I also prefer to keep the target-group as they currently are to keep
them simple. This is mostly a gut's feeling.
I am also interested to see soon a release of ant 1.8.0, so that the
community can enjoy the hundreds of bug fixes and improvements which are
contained in our current codebase.
Regards,
Antoine
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [POLL] target-groups
Posted by Stefan Bodewig <bo...@apache.org>.
On 2009-12-17, Bruce Atherton <br...@callenish.com> wrote:
> You've convinced me. Just because we can't think of a problem doesn't
> mean that one doesn't exist, and it is a little late in the day to
> start monkeying around if we want to get a new release out the door.
> So Stefan, as far as your poll is concerned, count me a +1 for the
> current code base.
I started writing my last answer before I read the complete thread, then
realized I had to brush snow from the pavement in front of our house and
send the kids to school, I ran out of time and revisited things a few
hours later.
So unless the <include>-naming thing I mentioned changes anybody's mind,
<target-group> as a marker seems to be acceptable as is the current code
base. We may make up out mind on further changes for later releases.
I'll let this settle for a day and start a poll on names after that as
well as propose a release plan.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [POLL] target-groups
Posted by Bruce Atherton <br...@callenish.com>.
You've convinced me. Just because we can't think of a problem doesn't
mean that one doesn't exist, and it is a little late in the day to start
monkeying around if we want to get a new release out the door.
So Stefan, as far as your poll is concerned, count me a +1 for the
current code base.
Dominique Devienne wrote:
> On Tue, Dec 15, 2009 at 7:53 PM, Bruce Atherton <br...@callenish.com> wrote:
>
>> Can anyone give a concrete example where there would be a problem treating a
>> target-group as if it were a target?
>>
>
> Can't. But my thinking is that we should ere on the conservative side
> when we introduce such a feature, and that it's easier to open it up
> later on to all targets with no BC issues, than closing it up because
> real world issues crop up, with BC issues. I really do believe that
> having target-group (or whatever the final name) purely abstract
> encourages better reusable build design by forcing to think in terms
> of the build's "public API" that provides clean "hooks" for reusable
> implementation-specific pieces to tack on. But as usual I seem to be
> in the minority and I certainly won't be casting any blocking votes on
> the matter. --DD
>
> ---------------------------------------------------------------------
> 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
Lexicon vs. grammar (was: [POLL] target-groups)
Posted by Jesse Glick <je...@sun.com>.
Dominique Devienne wrote:
> This allows to release sooner (1.7.1 is 18 months old), without rushing what is admittedly a more radical change to Ant's target dependency handling.
Agreed. More broadly, I would like to deflate discussions of this kind a bit. How many users are really clamoring for what I would refer to as grammatical changes in Ant
- interpretation of targets, property evaluation, and so on - and can also agree on what they want? Ant's grammar is awkward and often counterintuitive (IMHO), but with
experience it is possible to write what you need to write. If you need more flexibility and clarity, you can use <script>, or one of the ever-growing number of Ant-based
builder tools written in various JVM scripting languages. Changes to the existing grammar are relatively expensive in terms of design and implementation, and pose a high
risk of regressions, yet still cannot match the generality of true scripting languages.
In the meantime, the unique value of Ant does not lie in its grammar, but in its library of tasks, which have been tuned over the years to simplify access to a broad
variety of Java development tools and other file-manipulation utilities. The reason so many "alternative" build tools expose Ant tasks as their primary vocabulary is that
it would be impractical to offer anything as convenient and comprehensive starting from scratch.
I think it is best to be very conservative about the grammar. Focus energy on making standard tasks reliable, fast, and flexible (in that order).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [POLL] target-groups
Posted by Stefan Bodewig <bo...@apache.org>.
On 2009-12-16, Dominique Devienne <dd...@gmail.com> wrote:
> Sorry to hijack your POLL thread Stefan ;)
Thank you for doing so
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [POLL] target-groups
Posted by Dominique Devienne <dd...@gmail.com>.
2009/12/16 Nicolas Lalevée <ni...@hibnet.org>:
> [...] But targets are all "public"
Except for the tradition of having non-public targets' names start with a dash.
> So it seemed to me quite useless to try to restrict anything.
Restrict? More like caution, that's all. Lets not open Pandora's box
just yet on target dependencies, and provide a useful yet limited
extensible target (target-group), along with all the fixes Antoine
mentions. Lets see how it fairs in the wild and what users are
claiming for to make it more useful. This allows to release sooner
(1.7.1 is 18 months old), without rushing what is admittedly a more
radical change to Ant's target dependency handling.
Sorry to hijack your POLL thread Stefan ;) --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [POLL] target-groups
Posted by Nicolas Lalevée <ni...@hibnet.org>.
On Wed, 16 Dec 2009 08:51:27 -0600, Dominique Devienne
<dd...@gmail.com> wrote:
> On Tue, Dec 15, 2009 at 7:53 PM, Bruce Atherton <br...@callenish.com>
> wrote:
>> Can anyone give a concrete example where there would be a problem
>> treating a
>> target-group as if it were a target?
>
> Can't. But my thinking is that we should ere on the conservative side
> when we introduce such a feature, and that it's easier to open it up
> later on to all targets with no BC issues, than closing it up because
> real world issues crop up, with BC issues. I really do believe that
> having target-group (or whatever the final name) purely abstract
> encourages better reusable build design by forcing to think in terms
> of the build's "public API" that provides clean "hooks" for reusable
> implementation-specific pieces to tack on. But as usual I seem to be
> in the minority and I certainly won't be casting any blocking votes on
> the matter.
That's what I thought too, it would help defining what is public and part
of the API, which is one of my worry while maintaining the "build system" I
presented earlier. But targets are all "public", properties are global too.
So it seemed to me quite useless to try to restrict anything.
Or perhaps we could say it is a first step towards enabling proper API
specification in build scripts ?
Nicolas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [POLL] target-groups
Posted by Dominique Devienne <dd...@gmail.com>.
On Tue, Dec 15, 2009 at 7:53 PM, Bruce Atherton <br...@callenish.com> wrote:
> Can anyone give a concrete example where there would be a problem treating a
> target-group as if it were a target?
Can't. But my thinking is that we should ere on the conservative side
when we introduce such a feature, and that it's easier to open it up
later on to all targets with no BC issues, than closing it up because
real world issues crop up, with BC issues. I really do believe that
having target-group (or whatever the final name) purely abstract
encourages better reusable build design by forcing to think in terms
of the build's "public API" that provides clean "hooks" for reusable
implementation-specific pieces to tack on. But as usual I seem to be
in the minority and I certainly won't be casting any blocking votes on
the matter. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [POLL] target-groups
Posted by Bruce Atherton <br...@callenish.com>.
Sorry if the previous thread was hijacked by naming issues, but I'm not
sure I'm ready to vote in a poll yet.
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
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.
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). If they can be
treated as completely equivalent I'd favour what I've labelled as option
2 above. 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.
Can anyone give a concrete example where there would be a problem
treating a target-group as if it were a target?
Stefan Bodewig wrote:
> before we get carried away with naming discussions ...
>
> Currently I don't feel there is consensus of what we'd like to see with
> target-group (if anything at all). The options I see are
>
> * have some sort of composite of targets that other targets can add
> themselves to
>
> * have some special construct that has a depends list similar to
> target. targets can depend on such a construct and add themselves
> to the depends list (the current code base).
>
> * allow targets to add themselves to the depends lists of any other
> target
>
> * allow targets to add themselves to the depends lists of targets that
> in some way mark themselves as being open for such extensions
>
> * no target-group like construct at all
>
> * something completely different?
>
> What is your preference?
>
> 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