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