Right. I see a "part-of" relationship of arbitrary depth as being best
implemented using a Composite design pattern. A target-group is a
composite for targets but is itself also a target.
The level idea was only an example off the top of my head, but in
thinking about it you are right that numeric levels would be a bad
choice. The reason I thought of using numbers was so that the lower
layers would implicitly contain the higher ones but it really is obscure
and arbitrary from the users perspective.
Another solution would be to create different "interfaces" onto the
build file for different types of users running Ant. A "visibility"
attribute on targets could be set to the names of interfaces that could
be requested and would list that target if you ran Ant with the
interface specified, e.g. "-p=developer". You would need some new tag if
you wanted "extends" behaviour, though.
Yet another solution would be to add an attribute to allow stripping
descriptions from imported and included targets. Then the user could
write different top-level build files for different classes of users,
each choosing which imported targets got to keep their descriptions.
Or you could just live with the verbosity of the target list, like I
did, and use naming conventions in EasyAnt. I'm sure there are many
other ways to address the issue.
Gilles Scokart wrote:
I was asking to myself the same question : why only 2 levels?
I think you are right, we don't need different type of targets, what
we should have is a new type of relationship between targets : the
PartOf relationship that allow to plug a 'lower' level target INTO an
other target.
But for the idea of numerical level, I think it is going too far into
a strict layer decomposition. This might be too restrictive. Having
a PartOf relationship allow to do strict layering elegantly, but there
might be other usage to partOf.
If the only benefits of a numerical layer is to hava a -p1 .. -pn
options, then I think the benfit is too limited.
Gilles
2008/11/25 Bruce Atherton <[EMAIL PROTECTED]>:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
