Re: EasyAnt phases
2008/11/21 Stefan Bodewig <[EMAIL PROTECTED]>: > On 2008-11-20, Gilles Scokart <[EMAIL PROTECTED]> wrote: > >> 2008/11/20 Stefan Bodewig <[EMAIL PROTECTED]>: >>> On 2008-11-20, Gilles Scokart <[EMAIL PROTECTED]> wrote: > - What about the if/unless? > >>> This would be pretty hard to implement as you saw yourself later on. >>> What if the same target is in the depends list of two different >>> target-groups? > >> What about making an 'or' between the conditions ? > > Is this really what would be intended? What if one target-group has > an if attribute while the other one has not, or if the have > contradicting attributes? > > Stefan The idea is to plug a target into a target group. If a target is plugged into 2 target-group, and only one target group needs to be executed, then that target still needs to be executed to satisfy the execution of the other group. Concerning the conflict, we already have it with if and unless (it is just that they are closer). But I agree, it might be confusing. At least until we found a right view for the target and the target-group (something that I feel we don't have yet). -- Gilles Scokart - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt phases
On 2008-11-20, Gilles Scokart <[EMAIL PROTECTED]> wrote: > 2008/11/20 Stefan Bodewig <[EMAIL PROTECTED]>: >> On 2008-11-20, Gilles Scokart <[EMAIL PROTECTED]> wrote: >>> - What about the if/unless? >> This would be pretty hard to implement as you saw yourself later on. >> What if the same target is in the depends list of two different >> target-groups? > What about making an 'or' between the conditions ? Is this really what would be intended? What if one target-group has an if attribute while the other one has not, or if the have contradicting attributes? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt phases
2008/11/20 Stefan Bodewig <[EMAIL PROTECTED]>: > On 2008-11-20, Gilles Scokart <[EMAIL PROTECTED]> wrote: > >> There is 2 other topics : >> - What about the build events? > > As long as target-groups are not different from targets from the > perspective of the person who runs ant, not the person who writes the > build file, I don't see why. We are in line. > >> - What about the if/unless? > > This would be pretty hard to implement as you saw yourself later on. > What if the same target is in the depends list of two different > target-groups? What about making an 'or' between the conditions ? Am I still biased by a view "targets are put inside a target-group" ? > > 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]
Re: EasyAnt phases
On Wed, Nov 19, 2008 at 11:19 PM, Stefan Bodewig <[EMAIL PROTECTED]> wrote: > On 2008-11-19, Bruce Atherton <[EMAIL PROTECTED]> wrote: > >> The only other topic I saw brought up on this thread was whether a >> target-group should be allowed to have tasks in it rather than >> requiring it to be empty. > > If we allwed them to e non-empty, we could do away with target-group > completely and simply open up the depends list of all targets. Sorry, I'm not getting this. Can you expand on what you mean please? --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt phases
On 2008-11-20, Gilles Scokart <[EMAIL PROTECTED]> wrote: > There is 2 other topics : > - What about the build events? As long as target-groups are not different from targets from the perspective of the person who runs ant, not the person who writes the build file, I don't see why. > - What about the if/unless? This would be pretty hard to implement as you saw yourself later on. What if the same target is in the depends list of two different target-groups? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt phases
2008/11/19 Bruce Atherton <[EMAIL PROTECTED]>: > I think that summary does the job nicely. The only other topic I saw brought > up on this thread was whether a target-group should be allowed to have tasks > in it rather than requiring it to be empty. This can also be discussed > separately, though, if people feel strongly enough about it. > There is 2 other topics : - What about the build events? - What about the if/unless? Concerning the build events, It looks a very nice feature, but digging deeper I fear it doesn't work : In which group do you have init executed? The current interpretation is "targets are not executed inside a group, they are executed before the group is executed". A more interresting example is : The execution sequence will be a , b , foo , bar. This illustrates the view target-group is a group of targets inside which the targets are executed is wrong, and thus my idea of having events was wrong. Perhaps we should rename the concepts to not give the impression that this is something 'inside' which you can plug target. What about 'milestone', 'step', 'dynamic-target', 'goal' (who said 'phase'?). Concerning the if/unless, however, I still like the idea. Maybe the targets having a target-group should copy the if/unless of their target-group? (problem comes when there are multiple if/unless...) -- Gilles Scokart - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt phases
On 2008-11-19, Bruce Atherton <[EMAIL PROTECTED]> wrote: > The only other topic I saw brought up on this thread was whether a > target-group should be allowed to have tasks in it rather than > requiring it to be empty. If we allwed them to e non-empty, we could do away with target-group completely and simply open up the depends list of all targets. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt phases
I think that summary does the job nicely. The only other topic I saw brought up on this thread was whether a target-group should be allowed to have tasks in it rather than requiring it to be empty. This can also be discussed separately, though, if people feel strongly enough about it. Stefan Bodewig wrote: OK, with Matt's recent response it sounds as if we could add target-group as a new kind of target that is always empty and whose depends list other targets may append to while the build file is parsed. IMHO this much can be added to core right away. There have been discussions on whether we'd need more control over ordering of dependencies or a different interpretation of if/unless but these can be solved separately. Does that summary sound correct? Stefan - 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]
Re: EasyAnt phases
On 2008-11-18, Matt Benson <[EMAIL PROTECTED]> wrote: > it would seem the API necessary for a custom ProjectHelper to do > this already exists... absolutely. The question was whether ProjectHelper2 should do it directly. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt phases
On 2008-11-18, Jean-Louis BOUDART <[EMAIL PROTECTED]> wrote: > So any conclusions? > Does this feature should be integrated to ant-core? OK, with Matt's recent response it sounds as if we could add target-group as a new kind of target that is always empty and whose depends list other targets may append to while the build file is parsed. IMHO this much can be added to core right away. There have been discussions on whether we'd need more control over ordering of dependencies or a different interpretation of if/unless but these can be solved separately. Does that summary sound correct? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt phases
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote: > On 2008-11-18, Jean-Louis BOUDART > <[EMAIL PROTECTED]> wrote: > > > So any conclusions? > > At least no consensus. > > I'm not sure whether Matt is -0 or -1 on the > concept. At worst I'd be -0. :) Really if a target group is just a target whose dependencies can be joined at will be other targets, it would seem the API necessary for a custom ProjectHelper to do this already exists... so it's not a huge deal either way... -Matt > > Stefan > > - > 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]
Re: EasyAnt phases
On 2008-11-18, Jean-Louis BOUDART <[EMAIL PROTECTED]> wrote: > So any conclusions? At least no consensus. I'm not sure whether Matt is -0 or -1 on the concept. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt phases
> > > By typing "ant test -Dskip.test=true" you will not execute any target > > related to test target-group. > > Hmmm, I thought a target group basically had it's depends attribute > basically rewritten to include whatever target declared itself to be > part of this group, and since if/unless apply to the target's body and > not its dependencies, if/unless would have been useless on > target-groups. > > So either I assumed incorrectly how target-group was implemented, or > what you describe above (assuming depends attribute re-writing) is > incorrect. So which is it? *hides* My bad, i merged two different things in my answer :) Currently if /unless attribute is ignored on target-group. But it could be interresting feature (not yet implemented) to support that attribute to "skip" all task related to a given phase
Re: EasyAnt phases
On Tue, Nov 18, 2008 at 10:07 AM, Jean-Louis BOUDART <[EMAIL PROTECTED]> wrote: > As target-group is nothing more than a "target" so if/unless attribute is > supported. > Exemple > > unless="skip.test"/> > > ... > > > By typing "ant test" you will execute ALL target related to test > target-group So far so good. > By typing "ant test -Dskip.test=true" you will not execute any target > related to test target-group. Hmmm, I thought a target group basically had it's depends attribute basically rewritten to include whatever target declared itself to be part of this group, and since if/unless apply to the target's body and not its dependencies, if/unless would have been useless on target-groups. So either I assumed incorrectly how target-group was implemented, or what you describe above (assuming depends attribute re-writing) is incorrect. So which is it? > In opposite, > if you wanna execute explicitly "ant myTestTarget", phase attribute is > ignored (so skip.attribute should not be applied). That makes perfect sense. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt phases
Sorry i'm missed this mail 2008/11/14 Gilles Scokart <[EMAIL PROTECTED]> > 2008/11/13 Gilles Scokart <[EMAIL PROTECTED]>: > > I'm +1 to put the concept in Ant's core, marked as experimental. > > > > A question that I have is how deep we want to push this concept? > > > > A first level would be that a phase or a target-group is a "normal" > > tartget for which the depends is build based on the other target that > > are found. (with that view, I wonder by the way what motivate the fact > > that the phase have no tasks). > IMHO target-group are more powerfull when depending on other target-groups. I think this kind of target should stay as abstract as possible. This allow you more flexibilty. > > > > A second level (maybe I go too far) might be to put it deeper up to > > the event notification. A build that use phase might have > > phaseStarted and phaseFinished event sent around targetStarted and > > targetFinished. > This could be interresting A third level (or 2bis) : what will be the meaning if the if/unless > attribute on a phase ? > With the simple aproach in which phase are 'simple' targets, it does > nothing. But I think it would be more intuitice if that would mean > "do or skip all the target bound in that phase. As target-group is nothing more than a "target" so if/unless attribute is supported. Exemple ... By typing "ant test" you will execute ALL target related to test target-group By typing "ant test -Dskip.test=true" you will not execute any target related to test target-group. In opposite, if you wanna execute explicitly "ant myTestTarget", phase attribute is ignored (so skip.attribute should not be applied). Jean Louis
Re: EasyAnt phases
So any conclusions? Does this feature should be integrated to ant-core? or prove it's usefulness in EasyAnt & move it into core later if it truly proves useful ? 2008/11/14 Dominique Devienne <[EMAIL PROTECTED]> > On Fri, Nov 14, 2008 at 7:55 AM, Stefan Bodewig <[EMAIL PROTECTED]> > wrote: > > On 2008-11-13, Dominique Devienne <[EMAIL PROTECTED]> wrote: > > > >> This would be cleanly solved by the proto shown once a long time ago > >> by Conor (I believe), where dependencies could be specified *inside* > >> the target body. > > > > https://issues.apache.org/bugzilla/show_bug.cgi?id=12292 > > > > opened by Nicola Ken six years ago, with patch. > > Man, you're good :) I remembered the idea came from one of the Ant2 > protos, but not that Nicola Ken actually implemented it. > > I guess if it didn't fly then, it won't fly now tough. I'm actually > having trouble wrapping my head around all the ramifications this > would open, when I try to sort it out a bit more ;) --DD > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: EasyAnt phases
On Fri, Nov 14, 2008 at 7:55 AM, Stefan Bodewig <[EMAIL PROTECTED]> wrote: > On 2008-11-13, Dominique Devienne <[EMAIL PROTECTED]> wrote: > >> This would be cleanly solved by the proto shown once a long time ago >> by Conor (I believe), where dependencies could be specified *inside* >> the target body. > > https://issues.apache.org/bugzilla/show_bug.cgi?id=12292 > > opened by Nicola Ken six years ago, with patch. Man, you're good :) I remembered the idea came from one of the Ant2 protos, but not that Nicola Ken actually implemented it. I guess if it didn't fly then, it won't fly now tough. I'm actually having trouble wrapping my head around all the ramifications this would open, when I try to sort it out a bit more ;) --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt phases
On 2008-11-13, Dominique Devienne <[EMAIL PROTECTED]> wrote: > This would be cleanly solved by the proto shown once a long time ago > by Conor (I believe), where dependencies could be specified *inside* > the target body. https://issues.apache.org/bugzilla/show_bug.cgi?id=12292 opened by Nicola Ken six years ago, with patch. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt phases
2008/11/13 Gilles Scokart <[EMAIL PROTECTED]>: > I'm +1 to put the concept in Ant's core, marked as experimental. > > A question that I have is how deep we want to push this concept? > > A first level would be that a phase or a target-group is a "normal" > tartget for which the depends is build based on the other target that > are found. (with that view, I wonder by the way what motivate the fact > that the phase have no tasks). > > A second level (maybe I go too far) might be to put it deeper up to > the event notification. A build that use phase might have > phaseStarted and phaseFinished event sent around targetStarted and > targetFinished. > A third level (or 2bis) : what will be the meaning if the if/unless attribute on a phase ? With the simple aproach in which phase are 'simple' targets, it does nothing. But I think it would be more intuitice if that would mean "do or skip all the target bound in that phase. -- Gilles Scokart - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: EasyAnt phases
> > There is one change: the current Ant behavior is to respect the order in > > which dependencies are set. The phase as currently proposed does not deal > > with this, making it only usable in certain use cases. > > Someone correct me if I'm wrong here, but AFAIK there's nothing in the > documentation that states target dependencies will be executed in the > order listed. The fact that the default executor respects the order is a > side effect of the implementation, not a guaranteed behavior. While implementing the ParallelExecutor in the sandbox I got reaction in that case. http://marc.info/?l=ant-user&m=119797310406425&w=2 Basically order does matter (at the moment). But this was the basic idea of that executor: start all targets from the depends clause in parallel and start executing the current target if all finished without failure. But someone pointed out (http://marc.info/?l=ant-user&m=119797614510909&w=2) that the manual itself gives that hint: http://ant.apache.org/manual/using.html#targets "It should be noted, however, that Ant's depends attribute only specifies the order in which targets should be executed - it does not affect whether the target that specifies the dependency(s) gets executed if the dependent target(s) did not (need to) run. Ant tries to execute the targets in the depends attribute in the order they appear (from left to right). Keep in mind that it is possible that a target can get executed earlier when an earlier target depends on it." The need of clarification was said in http://marc.info/?l=ant-user&m=119797869814067&w=2 Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt phases
On 2008-11-13, Matt Benson <[EMAIL PROTECTED]> wrote:
> --- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
>> On 2008-11-11, Matt Benson <[EMAIL PROTECTED]>
>> wrote:
>>> Personally I would prefer supporting arbitrary attributes on
>>> targets.
>>> This would be less specific to EasyAnt and could have mileage for
>>> other Ant extensions.
Do you envision that we replace Target with UnknownElement and friends
or are you "just" thinking of a Property-Set that can be associated
with a target?
EasyAnt would still need a custom ProjectHelper to make sense of the
additional attributes, I don't see this as major a problem, though.
>> I read this as "I don't want the feature in core but provide hooks
>> to make live easier for EasyAnt", right?
> Pretty much, yeah, unless someone can make me see how "phases" (by
> whatever nomenclature) are relevant to basic Ant-fu. :)
OK, I'll try.
Take a look at the build file "infrastructure" (big word and it will
become worse ;-) for our antlibs, in particular
http://svn.apache.org/repos/asf/ant/antlibs/common/trunk/build.xml
It contains a number of empty targets with names like
"ready-to-compile" which are in there as extension points. If an
antlib needs to do something in addition to what ready-to-compile
does, it overrides the target with one of its own (which again depends
on the imported one).
This is a pattern you'll often find in build files designed for
re-use. I think Steve uses this in Smartfrog and I know I've used it
at work myself.
\begin{overstatement}
"phases" turn this design pattern into a language feature.
\end{overstatement}
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt phases
On 2008-11-14, Remie Bolte <[EMAIL PROTECTED]> wrote: > Perhaps it is possible to create a dependency between phases, and > additionally give targets the possibility to depend on a phase i.e.: > > > > > As EasyAnt's implementation stands, phases *are* targets, this means (or should mean) that targets and phases can depend on targets and phases. > Thanks again for taking the time to explain certain behavior and past > considerations. Some of my comments and suggestions might feel redundant for > those might have already been discussed in the past. Don't worry. Sometimes the one explaining something learns more by the very process of doing it than the one who listens, in in this case it may help us get the concept "right". Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt phases
Perhaps it is possible to create a dependency between phases, and additionally give targets the possibility to depend on a phase i.e.: (please don't mind the names, i'm not following this topic close enough to know them or make suggestions, it's just an example). This way it is possible for a target to rely on having a certain build phases executed. Personally, I don't see a good way of implementing ordering in phases, wheter or not this is desired. However, I think the concept of ordering and the community dependency on this behavior should be taken into this discussion. That was the only point I tried to make :) BTW: there are situation in our product builds where we specify the dependencies the way described by Dominique, using the antContrib runtarget task. I can image that having a dependency task that can be placed at any point inside a target allows more flexibility. Cheers, Remie p.s. Thanks again for taking the time to explain certain behavior and past considerations. Some of my comments and suggestions might feel redundant for those might have already been discussed in the past. On Fri, Nov 14, 2008 at 6:02 AM, Stefan Bodewig <[EMAIL PROTECTED]> wrote: > On 2008-11-13, Bruce Atherton <[EMAIL PROTECTED]> wrote: > > > Conceptually I agree with you, but I think we need to recognize why > > people would want this and to validate their concerns. > > I wasn't advocating we change the current behavior, Ant's own build > file relies on it in much the same way as > > > Consider these targets: > > > ... > > ... > > for example see the way we structure our test targets. > > depends="dump-info,junit-tests,antunit-tests,check-failed" > > and "check-failed" doesn't depend on anything, so with a different > executor model it might be run before any test has started. > > In the context of phases I think we don't need control over ordering > since the targets that want to add themselves to phases shouldn't > really depend on each other. If they do - that's what I meant to say > - then it smells as if an additional intermediate phase was missing. > > But your example got me thinking. It is pretty easy to imagine that > there would be "build" and "clean-build" phases much like what you > have shown with target. If my target wants to do something only in > the clean-build phase it will most likely make a difference whether it > is run before or after "clean". > > Stefan > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: EasyAnt phases
On 2008-11-13, Bruce Atherton <[EMAIL PROTECTED]> wrote: > Conceptually I agree with you, but I think we need to recognize why > people would want this and to validate their concerns. I wasn't advocating we change the current behavior, Ant's own build file relies on it in much the same way as > Consider these targets: > ... > ... for example see the way we structure our test targets.
Re: EasyAnt phases
Here is some additional information on EasyAnt phase concept http://easyant.abrm.info/trac/wiki/tasks/phase
Re: EasyAnt phases
On Thu, Nov 13, 2008 at 1:44 PM, Gilles Scokart <[EMAIL PROTECTED]> wrote: > A second level (maybe I go too far) might be to put it deeper up to > the event notification. A build that use phase might have > phaseStarted and phaseFinished event sent around targetStarted and > targetFinished. Makes sense to me. The Default Logger (or maybe another logger/listener) would then display target group information, helping make sense of the build output. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt phases
I'm +1 to put the concept in Ant's core, marked as experimental. A question that I have is how deep we want to push this concept? A first level would be that a phase or a target-group is a "normal" tartget for which the depends is build based on the other target that are found. (with that view, I wonder by the way what motivate the fact that the phase have no tasks). A second level (maybe I go too far) might be to put it deeper up to the event notification. A build that use phase might have phaseStarted and phaseFinished event sent around targetStarted and targetFinished. 2008/11/11 Stefan Bodewig <[EMAIL PROTECTED]>: > Hi all, > > EasyAnt has a concept named "phase" which is some special sort of > target. The main differences: > > * is always empty > > * its depends list is open for other targets to modify, i.e. targets > may add themselves as dependencies to a phase. > > It has been suggested to rename "phase" to "target-group". > > Without going into implementation details, do we want to add the > concept itself to Ant's core? > > If we don't I'll volunteer to help the EasyAnt people to hook the > concept into Ant without patching Ant itself. > > 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]
Re: EasyAnt phases
On Thu, Nov 13, 2008 at 1:08 PM, Bruce Atherton <[EMAIL PROTECTED]> wrote: > Conceptually I agree with you, but I think we need to recognize why people > would want this and to validate their concerns. > > Consider these targets: > > ... > ... > > Whether or not "clean" is a dependency of "compile" depends on the context > "compile" is executed in. Now, it is possible to work around this but I am > fairly sure that using dependencies as described above is a common > implementation pattern for our users. I know that I have used it in the > past, and probably will again. Sacrilege, I know. :-) Very good example Bruce, thanks. I also relied on the ordering in this case, and in my haste to advocate against relying on the ordering I forgot about it ;) The work around involves creating additional targets, which is inconvenient and leads to my dreaded "spaghetti Ant code". This would be cleanly solved by the proto shown once a long time ago by Conor (I believe), where dependencies could be specified *inside* the target body. This was a little mind-bending at first, but then you realize it's like creating implicit unnamed targets, and it solves the ordering issue nicely. Your above example would then become: --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt phases
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 and 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 , 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]
Re: EasyAnt phases
Conceptually I agree with you, but I think we need to recognize why people would want this and to validate their concerns. Consider these targets: ... ... Whether or not "clean" is a dependency of "compile" depends on the context "compile" is executed in. Now, it is possible to work around this but I am fairly sure that using dependencies as described above is a common implementation pattern for our users. I know that I have used it in the past, and probably will again. Sacrilege, I know. :-) For this specific feature, though, I don't believe the target-group should have ordering added to it. Specifying an order would needlessly complicate the use of the feature, as well as promoting behaviour that we generally consider "bad" for build systems. Since there is a workaround (providing ordering through the dependency tree), I think the unordered solution is better. But I wanted to make sure we fully understand the cost to our users of leaving it unordered. Stefan Bodewig wrote: 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt phases
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote: > On 2008-11-11, Matt Benson <[EMAIL PROTECTED]> > wrote: > > > Personally I would prefer supporting arbitrary > > attributes on targets. > > That would be easy to do. > > > This would be less specific to EasyAnt and could > have mileage for > > other Ant extensions. > > I read this as "I don't want the feature in core but > provide hooks to > make live easier for EasyAnt", right? Pretty much, yeah, unless someone can make me see how "phases" (by whatever nomenclature) are relevant to basic Ant-fu. :) -Matt > > Stefan > > - > 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]
Re: EasyAnt phases
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. > 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 and 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 , 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]
Re: EasyAnt phases
I agree that it doesn't make it right, however, it makes it a point to consider. One might even argue that the two do not exclude each other: in the current implementation an order depending design pattern and a DAG implementation can co-exist. Personally I would not vote for enforcing either design pattern for I think both have merit. Hence I also believe that it would serve the community to enable the possibility of ordered execution in the target-group / phase element. Maybe not as default behavior, but as additional feature. It doesn't make it right, but it probably will makes someones life a bit easier :) -r On Wed, Nov 12, 2008 at 6:37 PM, Jeffrey E Care <[EMAIL PROTECTED]> wrote: > "Remie Bolte" <[EMAIL PROTECTED]> wrote on 11/12/2008 11:42:05 AM: > > > > By declaring your target to be part of a given group, you are indeed > > > adding yourself as an *unordered* dependency on that phase (which is > > > just like a body-less target), but as you target you still have > > > dependencies, on other targets *or* target groups which will be what > > > dictates the ordering. If you specify your dependencies correctly, the > > > order will be correct. That's always been the case, and target groups > > > don't change that. > > > > There is one change: the current Ant behavior is to respect the order in > > which dependencies are set. The phase as currently proposed does not > deal > > with this, making it only usable in certain use cases. > > Someone correct me if I'm wrong here, but AFAIK there's nothing in the > documentation that states target dependencies will be executed in the > order listed. The fact that the default executor respects the order is a > side effect of the implementation, not a guaranteed behavior. > > The fact that many projects do in fact rely on target dependencies being > executed in listed order doesn't make it right.
Re: EasyAnt phases
"Remie Bolte" <[EMAIL PROTECTED]> wrote on 11/12/2008 11:42:05 AM: > > By declaring your target to be part of a given group, you are indeed > > adding yourself as an *unordered* dependency on that phase (which is > > just like a body-less target), but as you target you still have > > dependencies, on other targets *or* target groups which will be what > > dictates the ordering. If you specify your dependencies correctly, the > > order will be correct. That's always been the case, and target groups > > don't change that. > > There is one change: the current Ant behavior is to respect the order in > which dependencies are set. The phase as currently proposed does not deal > with this, making it only usable in certain use cases. Someone correct me if I'm wrong here, but AFAIK there's nothing in the documentation that states target dependencies will be executed in the order listed. The fact that the default executor respects the order is a side effect of the implementation, not a guaranteed behavior. The fact that many projects do in fact rely on target dependencies being executed in listed order doesn't make it right.
Re: EasyAnt phases
> By declaring your target to be part of a given group, you are indeed > adding yourself as an *unordered* dependency on that phase (which is > just like a body-less target), but as you target you still have > dependencies, on other targets *or* target groups which will be what > dictates the ordering. If you specify your dependencies correctly, the > order will be correct. That's always been the case, and target groups > don't change that. There is one change: the current Ant behavior is to respect the order in which dependencies are set. The phase as currently proposed does not deal with this, making it only usable in certain use cases. As a separate note, it's bad practice IMHO to rely on dependencies to > execute in the order a target specifies them. You should think in > terms of requirements for the target to complete successfully, and not > worry about the order. There's even a custom target executor that > removes the default Ant behavior to honor the order of the direct > dependencies and simply relies on the DAG topological sort, which is > the way to go in fact. --DD Dependencies in any way always have a specific order: you have a list of requirements, and sometimes they themselves also have a list of requirements, creating a nested dependency relationship. In complex designs, this will automatically result in a DAG scheme for the nested dependencies will probably have overlap. We are currently implementing the same view in our product builds. For optimization reasons, we use conditions to prevent duplicate execution of targets. Having said that, there are use-cases in which having an ordered execution of depending products makes sense, where implementing a DAG scheme would make our world more complex than truly required. It is probably also this pragmatic approach that caused the default target executor in Ant to still respect the dependency order. That same pragmatic argument could be used in this discussion: it would be a nice-to-have if it would be possible to influence the order in which targets are executed in the phase. However, I do see that this feature request creates an implementation nightmare :) Cheers, Remie
Re: EasyAnt phases
On Wed, Nov 12, 2008 at 6:00 AM, 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. It's no different from the current behavior Remie. target-groups or phases are indeed just like target dependency injection (good analogy Jeffrey!). By declaring your target to be part of a given group, you are indeed adding yourself as an *unordered* dependency on that phase (which is just like a body-less target), but as you target you still have dependencies, on other targets *or* target groups which will be what dictates the ordering. If you specify your dependencies correctly, the order will be correct. That's always been the case, and target groups don't change that. As a separate note, it's bad practice IMHO to rely on dependencies to execute in the order a target specifies them. You should think in terms of requirements for the target to complete successfully, and not worry about the order. There's even a custom target executor that removes the default Ant behavior to honor the order of the direct dependencies and simply relies on the DAG topological sort, which is the way to go in fact. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt phases
Hi, Thanks for the explanation, it indeed seems to be a nice feature, however my first concern would be the order of execution. I can imaging that the easiest way to implement is a first-in-first-out approach (or first-in-first-executed in this matter). 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. The required order is still defined using the depends attribute on targets. The order of registered targets will be defined by the attribute on the target-group, plus the targets that register themselves once they are loaded (load order is defined by normal processing of targets and imported build files). 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. 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? Or spent time thinking about the order in which targets or build files are imported into the project and processed. Is there a way to solve the issue of ordered execution? I think that would make it even more powerful. In addition, perhaps dynamic inclusion of build files (within targets) can be a valuable extension to this phase feature. 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)? Cheers, Remie On Wed, Nov 12, 2008 at 8:21 AM, Jeffrey E Care <[EMAIL PROTECTED]> wrote: > > "Remie Bolte" <[EMAIL PROTECTED]> wrote on 11/11/2008 11:05:48 AM: > > > Can you explain the concept of targets being able to add themselfs as > > dependencies? > > I can't really picture this :) > > I wasn't involved in the definition of this so don't take my word as > gospel, but this is my understanding: > > Assume you have a lot of projects & want to define a standard set of build > files (with a standard set of targets) for them all to use. You have a > "test" target for each project that can run any number of other targets to > perform specialized testing tasks: load testing, unit testing, etc. > > As things are today your standard test target needs to know about every > potential kind of testing that ANY of the projects MIGHT need to do & add > each of those other targets as a dependency. You basically then have to > define an empty implementation of each one of those specialized targets in > your standard set of build files, otherwise your test target will blow up > when building against one of your projects that doesn't implement some > particular kind of testing. > > This target-group concept turns that around; think of it as dependency > injection. It's defining a target name and saying "Hey, if you want to be > run when I run, please tell me" as opposed to the current situation of "Hey, > I know what I need to do without any help". It's a callback, an extension > point, an event listener, pick a metaphor. > > > Jeffrey E. (Jeff) Care [EMAIL PROTECTED] <[EMAIL PROTECTED]> > IBM WebSphere Application Server WAS Release Engineering > > [image: WebSphere Mosiac] [image: WebSphere Brandmark] > >
Re: EasyAnt phases
"Remie Bolte" <[EMAIL PROTECTED]> wrote on 11/11/2008 11:05:48 AM: > Can you explain the concept of targets being able to add themselfs as > dependencies? > I can't really picture this :) I wasn't involved in the definition of this so don't take my word as gospel, but this is my understanding: Assume you have a lot of projects & want to define a standard set of build files (with a standard set of targets) for them all to use. You have a "test" target for each project that can run any number of other targets to perform specialized testing tasks: load testing, unit testing, etc. As things are today your standard test target needs to know about every potential kind of testing that ANY of the projects MIGHT need to do & add each of those other targets as a dependency. You basically then have to define an empty implementation of each one of those specialized targets in your standard set of build files, otherwise your test target will blow up when building against one of your projects that doesn't implement some particular kind of testing. This target-group concept turns that around; think of it as dependency injection. It's defining a target name and saying "Hey, if you want to be run when I run, please tell me" as opposed to the current situation of "Hey, I know what I need to do without any help". It's a callback, an extension point, an event listener, pick a metaphor. Jeffrey E. (Jeff) Care [EMAIL PROTECTED] IBM WebSphere Application Server WAS Release Engineering
Re: EasyAnt phases
On 2008-11-11, Matt Benson <[EMAIL PROTECTED]> wrote: > Personally I would prefer supporting arbitrary > attributes on targets. That would be easy to do. > This would be less specific to EasyAnt and could have mileage for > other Ant extensions. I read this as "I don't want the feature in core but provide hooks to make live easier for EasyAnt", right? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt phases
On 2008-11-11, Remie Bolte <[EMAIL PROTECTED]> wrote: > Can you explain the concept of targets being able to add themselfs as > dependencies? > I can't really picture this :) You have one build file with something like as a template for Java compilation. This one gets imported or included in another build file that needs to generate some source files. This build file would contain ... and the phase attribute would add "generate-sources" to the depends attribute of "ready-to-compile". This is useful for build files that explicitly want to define extension points. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt phases
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote: > Hi all, > > EasyAnt has a concept named "phase" which is some > special sort of > target. The main differences: > > * is always empty > > * its depends list is open for other targets to > modify, i.e. targets > may add themselves as dependencies to a phase. > > It has been suggested to rename "phase" to > "target-group". > > Without going into implementation details, do we > want to add the > concept itself to Ant's core? > > If we don't I'll volunteer to help the EasyAnt > people to hook the > concept into Ant without patching Ant itself. > Personally I would prefer supporting arbitrary attributes on targets. This would be less specific to EasyAnt and could have mileage for other Ant extensions. -Matt > Stefan > > - > 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]
Re: EasyAnt phases
Hi, Can you explain the concept of targets being able to add themselfs as dependencies? I can't really picture this :) Cheers, Remie On Tue, Nov 11, 2008 at 12:25 PM, Stefan Bodewig <[EMAIL PROTECTED]> wrote: > Hi all, > > EasyAnt has a concept named "phase" which is some special sort of > target. The main differences: > > * is always empty > > * its depends list is open for other targets to modify, i.e. targets > may add themselves as dependencies to a phase. > > It has been suggested to rename "phase" to "target-group". > > Without going into implementation details, do we want to add the > concept itself to Ant's core? > > If we don't I'll volunteer to help the EasyAnt people to hook the > concept into Ant without patching Ant itself. > > Stefan > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: EasyAnt phases
On Tue, Nov 11, 2008 at 5:25 AM, Stefan Bodewig <[EMAIL PROTECTED]> wrote: > Without going into implementation details, do we want to add the > concept itself to Ant's core? +1 on the concept. Back in the days trying to design reusable builds around Ant's import, this would have made my life tons easier. To comment on Jeffrey's -0, I don't think this is something that can be implemented independently of Ant, and it's something that cleanly replaces the proposed pre and post targets, which were generally discussed as necessary. I'm happy to document it as experimental and possibly removed in the future if it doesn't pan out though. -0 to the phase name. +1 to the target-group name. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt phases
-0 on the concept; my preference would be to let the function prove it's usefulness in EasyAnt & move it into core later if it truly proves useful -1 on the "phase" name +1 on using "target-group" for the name Jeffrey E. (Jeff) Care [EMAIL PROTECTED] IBM WebSphere Application Server WAS Release Engineering From: Stefan Bodewig <[EMAIL PROTECTED]> To: dev@ant.apache.org Date: 11/11/2008 06:26 AM Subject: EasyAnt phases Hi all, EasyAnt has a concept named "phase" which is some special sort of target. The main differences: * is always empty * its depends list is open for other targets to modify, i.e. targets may add themselves as dependencies to a phase. It has been suggested to rename "phase" to "target-group". Without going into implementation details, do we want to add the concept itself to Ant's core? If we don't I'll volunteer to help the EasyAnt people to hook the concept into Ant without patching Ant itself. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
EasyAnt phases
Hi all, EasyAnt has a concept named "phase" which is some special sort of target. The main differences: * is always empty * its depends list is open for other targets to modify, i.e. targets may add themselves as dependencies to a phase. It has been suggested to rename "phase" to "target-group". Without going into implementation details, do we want to add the concept itself to Ant's core? If we don't I'll volunteer to help the EasyAnt people to hook the concept into Ant without patching Ant itself. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
