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