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 / vs
Swich done, everything works perfectly I like how you've documented it :) I've updated the patch (now it contains only phases features) http://easyant.abrm.info/trac/browser/trunk/src/main/patches/ant-713748-easyant-patch.diff Thanks again for this integration 2008/11/13 Stefan Bodewig <[EMAIL PROTECTED]> > > >> should help your caae. It isn's a complete fix since the prefix for > >> included files without "as" doesn't get set before the first target > >> (if any) is encountered. > > The "complete fix" should be revision 713745. > > Stefan > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: EasyAnt / vs
>> should help your caae. It isn's a complete fix since the prefix for >> included files without "as" doesn't get set before the first target >> (if any) is encountered. The "complete fix" should be revision 713745. 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-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 / vs
> >> by typing ant -p i can see
> >> org.apache.easyant#build-std-java.compile.iLikeToCompileJavaClasses -->
> i
> >> like to compile java classes :)
> >> org.apache.easyant#build-std-java.myPrefix.plop --> foo bar
>
> > This is what I get with Ant trunk:
>
> > $ ./build.sh -f ../../Temp/u.xml -p
> > Buildfile: c:\Temp\u.xml
>
> > Main targets:
>
> > compile.iLikeToCompileJavaClasses i like to compile java classes :)
> > myPrefix.plop foo bar
>
> unless I add an empty target to build-std-java in front of the
> includes. If I do, I get the same prefixed names that you get.
ok :)
So what is the expected behavior for prefix nesting?
>
> From my reading of what you expect it should be
>
> * import doesn't contribute to the prefix of d files
> at all
except if we explicitly give an "as" attribute for
>
> * s stack up to make a longer prefix
>
> Is this independent of whether the as asstribute (for either of the
> tasks) has been specified?
>
> Is there some rationale that makes the rules easy to memorize and
> document?
While using nested , stack up to make a longer prefix (the value of
the as attribute or the imported project's name attribute, if any).
doesn't contribute to the prefix of d files at all except
if we explicitly give an "as" attribute for .
>
>
> If my assumptions are correct then
>
>private String getTargetPrefix(AntXMLContext context) {
>String configuredValue = getCurrentTargetPrefix();
> if (configuredValue != null && configuredValue.length() == 0) {
>configuredValue = null;
>}
> if (configuredValue != null) {
>return configuredValue;
>}
>
>String projectName = context.getCurrentProjectName();
>if ("".equals(projectName)) {
>projectName = null;
>}
>
> + if (context.isIgnoringProjectTag() && isInIncludeMode()) {
>// help nested include tasks
>if (projectName != null) {
>setCurrentTargetPrefix(projectName);
>}
> + }
>
>return projectName;
>
> should help your caae. It isn's a complete fix since the prefix for
> included files without "as" doesn't get set before the first target
> (if any) is encountered.
Seems to work, thanks
Re: EasyAnt / vs
On 2008-11-13, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On 2008-11-13, Jean-Louis BOUDART <[EMAIL PROTECTED]> wrote:
>> I'll try to give you details
> [snip - removed > by typing ant -p i can see
>> org.apache.easyant#build-std-java.compile.iLikeToCompileJavaClasses --> i
>> like to compile java classes :)
>> org.apache.easyant#build-std-java.myPrefix.plop --> foo bar
> This is what I get with Ant trunk:
> $ ./build.sh -f ../../Temp/u.xml -p
> Buildfile: c:\Temp\u.xml
> Main targets:
> compile.iLikeToCompileJavaClasses i like to compile java classes :)
> myPrefix.plop foo bar
unless I add an empty target to build-std-java in front of the
includes. If I do, I get the same prefixed names that you get.
So what is the expected behavior for prefix nesting?
>From my reading of what you expect it should be
* import doesn't contribute to the prefix of d files
at all
* s stack up to make a longer prefix
Is this independent of whether the as asstribute (for either of the
tasks) has been specified?
Is there some rationale that makes the rules easy to memorize and
document?
If my assumptions are correct then
private String getTargetPrefix(AntXMLContext context) {
String configuredValue = getCurrentTargetPrefix();
if (configuredValue != null && configuredValue.length() == 0) {
configuredValue = null;
}
if (configuredValue != null) {
return configuredValue;
}
String projectName = context.getCurrentProjectName();
if ("".equals(projectName)) {
projectName = null;
}
+ if (context.isIgnoringProjectTag() && isInIncludeMode()) {
// help nested include tasks
if (projectName != null) {
setCurrentTargetPrefix(projectName);
}
+ }
return projectName;
should help your caae. It isn's a complete fix since the prefix for
included files without "as" doesn't get set before the first target
(if any) is encountered.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt / vs
On 2008-11-13, Jean-Louis BOUDART <[EMAIL PROTECTED]> wrote: > Here it is i'm ing a file that has no explicit "as" prefix. > So calling to (prefix = getTargetPrefix(context)) will return the imported > project's name. For the file's targets and only as an additional name, they should have been added without prefix a few lines above. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt / vs
> > It seems to be related to this test
> > if (!isInIncludeMode && context.isIgnoringProjectTag()
>
> means ProjectHelper is currently ing a file
>
> > && (prefix = getTargetPrefix(context)) != null
>
> and there is a prefix defined for the imported file (either an
> explicit "as" prefix or the imported project's name attribute)
Here it is i'm ing a file that has no explicit "as" prefix.
So calling to (prefix = getTargetPrefix(context)) will return the imported
project's name.
That's why i'm entering into the body of this test
>
>
> > && !isPhase) {
>
> Don't know how phase is supposed to factor into this.
>
> The body of that expression adds a prefixed target in addition to the
> non-prefixed target
>
> Adding yet another condition should make the body get executed less
> often, so I don't see why you should get a prefix if you make the body
> less likely to be executed.
>
> Is there a similar additional condition to the place where the
> unprefixed targets are added?
Nop :'(
http://easyant.abrm.info/trac/browser/trunk/src/main/patches/ant-713373-easyant-patch.diff
Re: EasyAnt / vs
On 2008-11-13, Jean-Louis BOUDART <[EMAIL PROTECTED]> wrote:
> Refering to the comment
> // In an imported file (and not completely ignoring the project tag
> *OR*having a preconfigured prefix)
> this test should be like this instead
> if (!isInIncludeMode && !isPhase && (context.isIgnoringProjectTag()
> || (prefix = getTargetPrefix(context)) != null)) {
No.
!isInIncludeMode means "either the main build file or ing a
file"
context.isIgnoringProjectTag() means "either ing or
ing"
so anding those two is the "In an imported file" part of the comment
(prefix = getTargetPrefix(context)) != null covers both branches of
the OR in "not completely ignoring the project tag OR having a
preconfigured prefix" since it will either return the configured
prefix or the 's name attribute.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt / vs
Refering to the comment
// In an imported file (and not completely ignoring the project tag
*OR*having a preconfigured prefix)
this test should be like this instead
if (!isInIncludeMode && !isPhase && (context.isIgnoringProjectTag()
|| (prefix = getTargetPrefix(context)) != null)) {
Maybe i'm getting wrong
2008/11/13 Jean-Louis BOUDART <[EMAIL PROTECTED]>
> It seems to be related to this test
> if (!isInIncludeMode && context.isIgnoringProjectTag()
> && (prefix = getTargetPrefix(context)) != null && !isPhase)
> {
>
> But i don't understand why yet :(
>
> Any idea?
>
> 2008/11/13 Stefan Bodewig <[EMAIL PROTECTED]>
>
>> On 2008-11-13, Jean-Louis BOUDART <[EMAIL PROTECTED]> wrote:
>>
>>
>> > I'll try to give you details
>>
>> [snip - removed >
>> > by typing ant -p i can see
>> > org.apache.easyant#build-std-java.compile.iLikeToCompileJavaClasses -->
>> i
>> > like to compile java classes :)
>> > org.apache.easyant#build-std-java.myPrefix.plop --> foo bar
>>
>> This is what I get with Ant trunk:
>>
>> $ ./build.sh -f ../../Temp/u.xml -p
>> Buildfile: c:\Temp\u.xml
>>
>> Main targets:
>>
>> compile.iLikeToCompileJavaClasses i like to compile java classes :)
>> myPrefix.plop foo bar
>>
>> This seems to be what you want, I just don't understand why your
>> result may be different. Could you please do a diff between your
>> ImportTask and ProjectHelper2 and Ant's svn trunk? You must have
>> missed/modified some part of trunk that is not related to phases.
>>
>> Stefan
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
Re: EasyAnt / vs
On 2008-11-13, Jean-Louis BOUDART <[EMAIL PROTECTED]> wrote:
> It seems to be related to this test
> if (!isInIncludeMode && context.isIgnoringProjectTag()
means ProjectHelper is currently ing a file
> && (prefix = getTargetPrefix(context)) != null
and there is a prefix defined for the imported file (either an
explicit "as" prefix or the imported project's name attribute)
> && !isPhase) {
Don't know how phase is supposed to factor into this.
The body of that expression adds a prefixed target in addition to the
non-prefixed target
Adding yet another condition should make the body get executed less
often, so I don't see why you should get a prefix if you make the body
less likely to be executed.
Is there a similar additional condition to the place where the
unprefixed targets are added?
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt / vs
It seems to be related to this test
if (!isInIncludeMode && context.isIgnoringProjectTag()
&& (prefix = getTargetPrefix(context)) != null && !isPhase)
{
But i don't understand why yet :(
Any idea?
2008/11/13 Stefan Bodewig <[EMAIL PROTECTED]>
> On 2008-11-13, Jean-Louis BOUDART <[EMAIL PROTECTED]> wrote:
>
> > I'll try to give you details
>
> [snip - removed
> > by typing ant -p i can see
> > org.apache.easyant#build-std-java.compile.iLikeToCompileJavaClasses --> i
> > like to compile java classes :)
> > org.apache.easyant#build-std-java.myPrefix.plop --> foo bar
>
> This is what I get with Ant trunk:
>
> $ ./build.sh -f ../../Temp/u.xml -p
> Buildfile: c:\Temp\u.xml
>
> Main targets:
>
> compile.iLikeToCompileJavaClasses i like to compile java classes :)
> myPrefix.plop foo bar
>
> This seems to be what you want, I just don't understand why your
> result may be different. Could you please do a diff between your
> ImportTask and ProjectHelper2 and Ant's svn trunk? You must have
> missed/modified some part of trunk that is not related to phases.
>
> Stefan
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Re: EasyAnt / vs
On 2008-11-13, Jean-Louis BOUDART <[EMAIL PROTECTED]> wrote: > I'll try to give you details [snip - removed by typing ant -p i can see > org.apache.easyant#build-std-java.compile.iLikeToCompileJavaClasses --> i > like to compile java classes :) > org.apache.easyant#build-std-java.myPrefix.plop --> foo bar This is what I get with Ant trunk: $ ./build.sh -f ../../Temp/u.xml -p Buildfile: c:\Temp\u.xml Main targets: compile.iLikeToCompileJavaClasses i like to compile java classes :) myPrefix.plop foo bar This seems to be what you want, I just don't understand why your result may be different. Could you please do a diff between your ImportTask and ProjectHelper2 and Ant's svn trunk? You must have missed/modified some part of trunk that is not related to phases. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
