2008/11/13 Stefan Bodewig <[EMAIL PROTECTED]>: > On 2008-11-12, Remie Bolte <[EMAIL PROTECTED]> wrote: > >> Thanks for the explanation, it indeed seems to be a nice feature, however my >> first concern would be the order of execution. > > If you need a specific order of execution, you should ensure that your > depends attributes are correct. If target "a" must be run before > target "b" than "b" simply must depend upon "a". > > This is true with normal targets and I don't see why target-groups > would change that. >
My understanding is that the phase allow to incorporate targets that doesn't know each other. In that context imposing an order doesn't make sense. But I can imagine that when implementing 2 independent sets of targets to be bound in a phase, you realize that they will only work properly together when executed in a specific order. For such a case, the user will have no other choice than adding a phase. Indeed, he probably doesn't know if the 2 sets of targets will be always used together. If such scenario is realistics then, we may also need to have a "depends if executed" meaning that if target b must be executed, then it must be before target a. I think some experimentation will say if such ordering mechanism is required. At the opposite, I could also imagine that the implementation make sure that the targets are isolated. I could imagine that the bounded target are executed in isolation, and that all the properties and reference that are defined are only visible when the phase is finished. I think both aproach are too extreme for the moment. The guideline (and the purpose) should be to have the possibility to bind independant targets into a phase. >> If I understand correctly the target-group, or phase (would be my >> preference), is a very top-level element that simply specifies a grouping of >> tasks, it doesn't deal with the order in which tasks are performed. > > It really only is a target, yes. And it only exists for its depends > list. If the targets it depends on require a specific order, they > better say so in their own depends lists. If they can't, then this > may hint at a missing phase. > >> So, this target-group element is only useful if order doesn't matter >> in the phase, like in the example of having different types of >> tests. If order does matter, this would then needed to be solved >> using the depends attribute. > > Yes. > >> But that also requires making sure that certain targets are not >> executed twice, which means one would need to add succeeded >> properties and have unless conditions to check them, right? > > I don't think so. targets will never run twice unless you do > something like running "ant a b" on the command line where b depends > on a. > >> In addition, perhaps dynamic inclusion of build files (within targets) can >> be a valuable extension to this phase feature. > > Right now <import> and <include> must be used outside of targets and > it would be pretty difficult to implement in any other way. > > The imported files define new targets. If you import a file while > executing a target you are modifiying the DAG of the running build > targets. > >> Different question, but maybe related: is there a way to specify >> that a build file should only be imported once (for instance, if >> different nested files have import statements referring to the same >> file)? > > This is the current behavior of <import>, any file will only be > imported once and subsequent imports are ignored. > > Stefan > > --------------------------------------------------------------------- > 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]
