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] > > -- Gilles Scokart --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
