I am in the same boat as Stefan. I also don't understand yet why
target-groups are not just targets to the person running Ant.
What you appear to be arguing here is that there should be two levels to
Ant targets. But why just two? Why not three or four or five?
I've written build systems this way in the past. Here is an example:
Level 1 = top level targets that span multiple modules, depend on level
2 targets and add timestamps to logs. Description defined.
Level 2 = top level targets for a specific module, depend on level 3
targets and add timestamps to logs. Description defined.
Level 3 = more granular targets that encapsulate reusable sets of
behaviour, depend on level 3 and 4 targets. No description.
Level 4 = fine-grained targets, depend only on initialization targets.
Used when you know exactly the state of your environment and want to do
something specific with no time wasted, like in a developer sandbox.
Description defined.
Level 5 = initialization targets. No description.
I used naming conventions for targets to differentiate the levels. For
example, level 4 targets all ended with "-only" to indicate there were
few dependencies being run. There are other solutions, though. Perhaps
targets could have a "level" attribute and -projecthelp could take an
optional numeric parameter to indicate the level you want to see.
Someone building a module could run "ant -p2" to find out which targets
were available to them. A developer could run "ant -p4". To make things
more user-friendly, EasyAnt could define a standard set of levels and
name them rather than using numbers.
That is just one idea. Regardless, I think a more general solution would
be better than treating target-groups in a special way, or even worse by
adding target-parts to the mix. But then again, I may be missing something.
Jean-Louis BOUDART wrote:
I agree with Xavier a target-group is something at a higher level than a
target.
I think that the key feature of target-group is dependency injection but as
Xavier says "if thread-group is the only way to have target dependency
injection, then people may use it only for that, and complain about the
distinction in project help".
The fact is target-group is not only a way to have dependency management,
but a "new way" to think your build-script.
I guess for us target-group is useful to make build modules easily reusable
in a standard build (with standard target-group), without requiring any
specific orchestration.
This means target-group allow you to have a kind of "generic target", that's
why in EasyAnt we want to have separated help for generic targets
(target-group) and specific target (normal target).
In addition, as we use target-group to have more "genericity" we doesn't
want to have prefix on those "generic" targets.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
