Re: target-group committed
I'm +1 for this solution 2008/11/26 Dominique Devienne [EMAIL PROTECTED] On Wed, Nov 26, 2008 at 2:06 PM, Bruce Atherton [EMAIL PROTECTED] wrote: 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. One possible way would be to provide an in-build-file hook to intercept the -p switch, and this hook (I envision a target) would then be responsible to display the help. Couple that with a new configurable task to generate the -p output, and then it's up to the user to select (via some kind of include/exclude) whatever targets are going to be listed. My builds used to all have a help target which java'd back into Ant on the same build file with the -p switch added. It's the same idea, but exposing a builtin task instead, and allowing to run that target when -p is specified, if it's hooked via for example a project help-target=help. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: target-group committed
Any news on this point? 2008/11/24 Xavier Hanin [EMAIL PROTECTED] On Fri, Nov 21, 2008 at 12:26 AM, Jean-Louis BOUDART [EMAIL PROTECTED] wrote: In addition, as we use target-group to have more genericity we doesn't want to have prefix on those generic targets. I'm afraid I don't understand this. One of your selling points for include was that the included build is self-contained and remains that way by prefixing all traget names and rewriting the depends lists. If we break that rule for some kind of target, the included build is suddenly open for modifications from the outside - including overrides of target-groups. Again if we consider target-group as JUST a way to have target dependency injection, this doesn't make sens. In opposite if we consider that target-groups are toplevel target does't it make sens to have prefix on target-group? Example (using current HEAD revision): Suppose you want to have a generic task called report a.xml project name=A target name=javadoc target-group=report description=generate javadoc echojavadoc/echo /target ... /project b.xml project name=B target name=junitreport target-group=report description=generate junit report echojunitreport/echo /target ... /project c.xml project name=C target name=emma-report description=generate emma report target-group=report echo emma report/echo /target ... /project phases.xml project name=phases target-group name=report description=generate all report for your project / /project build.xml project name=generic-build import file=phase.xml/ include file=a.xml as=javadoc/ include file=b.xml as=junit/ include file=c.xml as=emma/ /project If you try to use ant report : you have this message can't add target javadoc.javadoc to target-group javadoc.report because the target-group is unknown. IMHO a target-group should NEVER be prefixed, in a module it's possible to assign a target to a phase which is not declared in the build module. It makes the module dependent on the caller to declare the phase prior to the use call, and as such becomes a requirement of the module. I would like to bring more attention to this, because I think Jean-Louis makes a very good point here. IMO joining a target group for a target should be possible for a target group which is defined in a build file including the build file in which the target itself is defined. So maybe name resolution of a target-group when a target declares to join a target-group (with target name=foo target-group=bar /) in an included file should first look for the prefixed name (as it is currently implemented) and then if it doesn't exist, try to look for the non prefixed name. WDYT? -- Xavier Hanin - 4SH France BordeauxJUG co leader - http://www.bordeauxjug.org/ Blogger - http://xhab.blogspot.com/ Apache Ivy Creator - http://ant.apache.org/ivy/
Re: target-group committed
On 2008-11-28, Jean-Louis BOUDART [EMAIL PROTECTED] wrote: Any news on this point? I've still not seen any argument that convinced me that the naming rules for include should be different, but that's just me. On the target-group as composite side, I may start to understand it, but feel that we've been tackling the wrong way. Instead of madifying depends, target-group should have a parts attribute that targets can append to. Or something like that. I haven't made up my mind on any of this. But like I said, it is just me, don't wait for me. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: target-group committed
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]
Re: target-group committed
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
Re: target-group committed
On Wed, Nov 26, 2008 at 2:06 PM, Bruce Atherton [EMAIL PROTECTED] wrote: 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. One possible way would be to provide an in-build-file hook to intercept the -p switch, and this hook (I envision a target) would then be responsible to display the help. Couple that with a new configurable task to generate the -p output, and then it's up to the user to select (via some kind of include/exclude) whatever targets are going to be listed. My builds used to all have a help target which java'd back into Ant on the same build file with the -p switch added. It's the same idea, but exposing a builtin task instead, and allowing to run that target when -p is specified, if it's hooked via for example a project help-target=help. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: target-group committed
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]
Re: target-group committed
On Fri, Nov 21, 2008 at 12:26 AM, Jean-Louis BOUDART [EMAIL PROTECTED] wrote: In addition, as we use target-group to have more genericity we doesn't want to have prefix on those generic targets. I'm afraid I don't understand this. One of your selling points for include was that the included build is self-contained and remains that way by prefixing all traget names and rewriting the depends lists. If we break that rule for some kind of target, the included build is suddenly open for modifications from the outside - including overrides of target-groups. Again if we consider target-group as JUST a way to have target dependency injection, this doesn't make sens. In opposite if we consider that target-groups are toplevel target does't it make sens to have prefix on target-group? Example (using current HEAD revision): Suppose you want to have a generic task called report a.xml project name=A target name=javadoc target-group=report description=generate javadoc echojavadoc/echo /target ... /project b.xml project name=B target name=junitreport target-group=report description=generate junit report echojunitreport/echo /target ... /project c.xml project name=C target name=emma-report description=generate emma report target-group=report echo emma report/echo /target ... /project phases.xml project name=phases target-group name=report description=generate all report for your project / /project build.xml project name=generic-build import file=phase.xml/ include file=a.xml as=javadoc/ include file=b.xml as=junit/ include file=c.xml as=emma/ /project If you try to use ant report : you have this message can't add target javadoc.javadoc to target-group javadoc.report because the target-group is unknown. IMHO a target-group should NEVER be prefixed, in a module it's possible to assign a target to a phase which is not declared in the build module. It makes the module dependent on the caller to declare the phase prior to the use call, and as such becomes a requirement of the module. I would like to bring more attention to this, because I think Jean-Louis makes a very good point here. IMO joining a target group for a target should be possible for a target group which is defined in a build file including the build file in which the target itself is defined. So maybe name resolution of a target-group when a target declares to join a target-group (with target name=foo target-group=bar /) in an included file should first look for the prefixed name (as it is currently implemented) and then if it doesn't exist, try to look for the non prefixed name. WDYT? -- Xavier Hanin - 4SH France BordeauxJUG co leader - http://www.bordeauxjug.org/ Blogger - http://xhab.blogspot.com/ Apache Ivy Creator - http://ant.apache.org/ivy/
AW: target-group committed
In addition, as we use target-group to have more genericity we doesn't want to have prefix on those generic targets. I'm afraid I don't understand this. One of your selling points for include was that the included build is self-contained and remains that way by prefixing all traget names and rewriting the depends lists. If we break that rule for some kind of target, the included build is suddenly open for modifications from the outside - including overrides of target-groups. Again if we consider target-group as JUST a way to have target dependency injection, this doesn't make sens. In opposite if we consider that target-groups are toplevel target does't it make sens to have prefix on target-group? Example (using current HEAD revision): Suppose you want to have a generic task called report a.xml project name=A target name=javadoc target-group=report description=generate javadoc echojavadoc/echo /target ... /project b.xml project name=B target name=junitreport target-group=report description=generate junit report echojunitreport/echo /target ... /project c.xml project name=C target name=emma-report description=generate emma report target-group=report echo emma report/echo /target ... /project phases.xml project name=phases target-group name=report description=generate all report for your project / /project build.xml project name=generic-build import file=phase.xml/ include file=a.xml as=javadoc/ include file=b.xml as=junit/ include file=c.xml as=emma/ /project If you try to use ant report : you have this message can't add target javadoc.javadoc to target-group javadoc.report because the target-group is unknown. IMHO a target-group should NEVER be prefixed, in a module it's possible to assign a target to a phase which is not declared in the build module. It makes the module dependent on the caller to declare the phase prior to the use call, and as such becomes a requirement of the module. I would like to bring more attention to this, because I think Jean-Louis makes a very good point here. IMO joining a target group for a target should be possible for a target group which is defined in a build file including the build file in which the target itself is defined. So maybe name resolution of a target-group when a target declares to join a target-group (with target name=foo target-group=bar /) in an included file should first look for the prefixed name (as it is currently implemented) and then if it doesn't exist, try to look for the non prefixed name. Could we write a Wiki page with the definitions? (Its content could after committing be moved to the manual) Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: target-group committed
On 2008-11-21, Jean-Louis BOUDART [EMAIL PROTECTED] wrote: Suppose you have a build with 10 target-group which represent 10 different generic step of your build process (like compile / package/ test/ etc...) Then I'd consider this to be the public API and import it. And behind you have 30 submodules that have one or many target associated (or not) to that target-groups (compile-java,compile-scala,compile-whatever,javadoc,etc) They'd be implementation details of the public API and I'd include them. As target-group are top-level target, as a user i would prefer to see target-group separated instead of having to lookup at ALL target available. So you are really asking for a way to suppress the targets that are merely implementation details, or to de-emphasize them. What you really want is a distinction between public targets and their implementations. This distiction isn't necessarily the same as the one between targets and target-groups. I coud very well envision public targets and not-so-public target-groups. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: target-group committed
On Thu, Nov 20, 2008 at 6:22 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: On 2008-11-19, Jean-Louis BOUDART [EMAIL PROTECTED] wrote: I just have two questions : I knew I didn't reproduce all of EasyAnt's patch 8-) - Does prefix of import / include make sense on target-group? Or should we consider target-group as an abstract target that is never prefixed? To me target-groups should be treated just like targets by import and include so I made the same prefix rules apply. Why would you want to have different rules? Wouldn't that defeat the purpose of include? - When displaying projecthelp should we have target and target-group mixed? or should we have a distinction? From the user's (the one running the build not writing the build file) there shouldn't really be any difference so I wouldn't report them separately. That may be just me. I'm not sure if it's directly related to thread-group, or to the usage made of thread-group in EasyAnt: when using thread-groups as phases, it is better to have them isolated in project help, even from a user point of view. But when used only as a way to inject target dependencies, the user doesn't have to know about that. But maybe the point is that we should isolate the thread-group concept from target dependency injection. IMO a thread-group is something at a higher level than a target (as the name implies), something which was missing in Ant IMO, especially for large build systems based on Ant. As such I think it deserves isolation in project help. But 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. So maybe we should introduce target dependency injection for regular targets too? I'm not sure how useful it is though, just throwing ideas. Xavier Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Xavier Hanin - 4SH France BordeauxJUG co leader - http://www.bordeauxjug.org/ Blogger - http://xhab.blogspot.com/ Apache Ivy Creator - http://ant.apache.org/ivy/
Re: target-group committed
On 2008-11-19, Stefan Bodewig [EMAIL PROTECTED] wrote: Maybe this should be a comma-separeted list of traget-groups to add to instead. [Maybe I should proof-read my mails before I hit C-c C-c.] The target-group attribute now accepts a comma-separated list in svn revision 719198. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: target-group committed
I think if you want to show nice dynamic help, with rich (understand specific) logic to select what to display, you should probably use an help module in EasyAnt, (I mean an imported help build file exposing an help target ot target-group). Gilles 2008/11/20 Xavier Hanin [EMAIL PROTECTED]: On Thu, Nov 20, 2008 at 6:22 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: On 2008-11-19, Jean-Louis BOUDART [EMAIL PROTECTED] wrote: I just have two questions : I knew I didn't reproduce all of EasyAnt's patch 8-) - Does prefix of import / include make sense on target-group? Or should we consider target-group as an abstract target that is never prefixed? To me target-groups should be treated just like targets by import and include so I made the same prefix rules apply. Why would you want to have different rules? Wouldn't that defeat the purpose of include? - When displaying projecthelp should we have target and target-group mixed? or should we have a distinction? From the user's (the one running the build not writing the build file) there shouldn't really be any difference so I wouldn't report them separately. That may be just me. I'm not sure if it's directly related to thread-group, or to the usage made of thread-group in EasyAnt: when using thread-groups as phases, it is better to have them isolated in project help, even from a user point of view. But when used only as a way to inject target dependencies, the user doesn't have to know about that. But maybe the point is that we should isolate the thread-group concept from target dependency injection. IMO a thread-group is something at a higher level than a target (as the name implies), something which was missing in Ant IMO, especially for large build systems based on Ant. As such I think it deserves isolation in project help. But 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. So maybe we should introduce target dependency injection for regular targets too? I'm not sure how useful it is though, just throwing ideas. Xavier Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Xavier Hanin - 4SH France BordeauxJUG co leader - http://www.bordeauxjug.org/ Blogger - http://xhab.blogspot.com/ Apache Ivy Creator - http://ant.apache.org/ivy/ -- Gilles Scokart - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: target-group committed
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.
Re: target-group committed
On 2008-11-20, Xavier Hanin [EMAIL PROTECTED] wrote: I'm not sure if it's directly related to thread-group, or to the usage made of thread-group in EasyAnt: could you please explain what a thread-group in EasyAnt is/does? Thanks Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: target-group committed
I think this is a typo he wanted to say target-group IMHO :p 2008/11/20 Stefan Bodewig [EMAIL PROTECTED] On 2008-11-20, Xavier Hanin [EMAIL PROTECTED] wrote: I'm not sure if it's directly related to thread-group, or to the usage made of thread-group in EasyAnt: could you please explain what a thread-group in EasyAnt is/does? Thanks Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: target-group committed
On 2008-11-20, Jean-Louis BOUDART [EMAIL PROTECTED] wrote: The fact is target-group is not only a way to have dependency management, but a new way to think your build-script. Yes, but only for the person who writes the build file, not the one who uses it. -projecthelp is for the user. 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). Why would the user care whether she invokes a generic or specific target? In addition, as we use target-group to have more genericity we doesn't want to have prefix on those generic targets. I'm afraid I don't understand this. One of your selling points for include was that the included build is self-contained and remains that way by prefixing all traget names and rewriting the depends lists. If we break that rule for some kind of target, the included build is suddenly open for modifications from the outside - including overrides of target-groups. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: target-group committed
The fact is target-group is not only a way to have dependency management, but a new way to think your build-script. Yes, but only for the person who writes the build file, not the one who uses it. -projecthelp is for the user. 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). Why would the user care whether she invokes a generic or specific target? Suppose you have a build with 10 target-group which represent 10 different generic step of your build process (like compile / package/ test/ etc...) And behind you have 30 submodules that have one or many target associated (or not) to that target-groups (compile-java,compile-scala,compile-whatever,javadoc,etc) As target-group are top-level target, as a user i would prefer to see target-group separated instead of having to lookup at ALL target available. In the case where target and target-group are mixed how would you (as a user) make the difference of what is a TOP level target (ie a generic task) and a specific target? I guess usign ant compile has MORE consequences than using ant compile-java. Maybe my example is not enough revelent :'( Here is a short example of EasyAnt project help : Main phases: compile compile the source code of the project generate-resources generate resources for inclusion in the package generate-sourcesgenerate any source code for inclusion in compilation integration-testprocess and deploy the package if necessary into an environment where integration tests can be run package take the compiled code and package it in its distributable format, such as a JAR. post-integration-test perform actions required after integration tests have been executed. This may including cleaning up the environment pre-integration-testperform actions required before integration tests are executed. This may involve things such as setting up the required environment prepare-package perform any operations necessary to prepare a package before the actual packaging. This often results in an unpacked, processed version of the package process-classes post-process the generated files from compilation, for example to do bytecode enhancement on Java classes process-resources copy and process the resources into the destination directory, ready for packaging process-sources process the source code, for example to filter any values provision supply provision required by this project publish-local publish the package into the local repository, for use as a dependency in other projects locally publish-shared done in an integration environment, copies the final package to the remote repository for sharing with other developers and projects release done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects report generate report testrun tests using a suitable unit testing framework. These tests should not require the code be packaged or deployed test-compilecompile the test source code into the test destination directory test-generate-resources create resources for testing test-generate-sources generate any test source code for inclusion in compilation test-process-resources copy and process the resources into the test destination directory test-process-sourcesprocess the test source code, for example to filter any values test-provision supply provision required to test this project validatevalidate the project is correct and all necessary information is available verify run any checks to verify the package is valid and meets quality criteria Main targets: checkstyle:checkstyle generate checkstyle report clean:clean clean project doc:documentation generate documentation emma:emma generate emma covera report jar:jar package project as a JAR javadoc:javadoc generate javadoc report for main classes and test classes lib-resolve resolve and retrieve dependencies with ivy lib:common-ivy:clean-cache clean the ivy cache lib:common-ivy:clean-libclean the project libraries directory lib:common-ivy:report generate dependencies report publish:clean-local cleans the local repository run:run run the application source:main package main source
target-group committed
Hi all, svn revision 718943 contains target-group (without documentation) as a special kind of target that must always be empty. targets and target-groups have a new attribute target-group that can be used to add the target(-group) to a named target-group that must have been defined already[1]. Maybe this should be a comma-separeted list of traget-groups to add to instead. Dependenices are always appended. I think I got the naming conventions of include right, but there will be some import scenarios that haven't been covered (like the imporitng build file naming a plain target the same as an imported target-group). Shout if I shall pull it again or if you don't like the implementation. Stefan [1] sounds complex, but isn't. Take a look at http://svn.apache.org/repos/asf/ant/core/trunk/src/tests/antunit/core/target-group-test.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: target-group committed
svn revision 718943 contains target-group (without documentation) as a special kind of target that must always be empty. targets and target-groups have a new attribute target-group that can be used to add the target(-group) to a named target-group that must have been defined already[1]. Maybe this should be a comma-separeted list of traget-groups to add to instead. Dependenices are always appended. Nice ! I think I got the naming conventions of include right, but there will be some import scenarios that haven't been covered (like the imporitng build file naming a plain target the same as an imported target-group). I just have two questions : - Does prefix of import / include make sense on target-group? Or should we consider target-group as an abstract target that is never prefixed? - When displaying projecthelp should we have target and target-group mixed? or should we have a distinction? Exemple : project name=org.apache.ant#jar target name=compile-java target-group=compile description=compile java classes on the current project /target target name=package-jar target-group=package description=package this project as a jar /target /project project name=generic target-group name=compile description=compile the current projet/ target-group name=package description=package the current project depends=compile/ include file=/path/to/jar.xml as=jar / /project By typing ant -p 1) Case of target and target-group mixed project help will display something like :*Available target :* compile -- compile the current projet compile-java -- compile java classes on the current project package -- package the current project package-jar -- package this project as a jar 2) Case when target and target-group are separated *Available target-group :* compile-java -- compile java classes on the current project package-jar -- package this project as a jar *Available target :* compile -- compile the current projet package -- package the current project Regards Jean Louis
Re: target-group committed
Hum little mistake in my explanation : By typing ant -p 1) Case of target and target-group mixed project help will display something like :*Available target :* compile -- compile the current projet org.apache.ant#jar.compile-java -- compile java classes on the current project package -- package the current project org.apache.ant#jar.package-jar -- package this project as a jar 2) Case when target and target-group are separated *Available target-group :* compile-java -- compile java classes on the current project package-jar -- package this project as a jar *Available target :* compile -- compile the current projet package -- package the current project 2008/11/19 Jean-Louis BOUDART [EMAIL PROTECTED] svn revision 718943 contains target-group (without documentation) as a special kind of target that must always be empty. targets and target-groups have a new attribute target-group that can be used to add the target(-group) to a named target-group that must have been defined already[1]. Maybe this should be a comma-separeted list of traget-groups to add to instead. Dependenices are always appended. Nice ! I think I got the naming conventions of include right, but there will be some import scenarios that haven't been covered (like the imporitng build file naming a plain target the same as an imported target-group). I just have two questions : - Does prefix of import / include make sense on target-group? Or should we consider target-group as an abstract target that is never prefixed? - When displaying projecthelp should we have target and target-group mixed? or should we have a distinction? Exemple : project name=org.apache.ant#jar target name=compile-java target-group=compile description=compile java classes on the current project /target target name=package-jar target-group=package description=package this project as a jar /target /project project name=generic target-group name=compile description=compile the current projet/ target-group name=package description=package the current project depends=compile/ include file=/path/to/jar.xml as=jar / /project By typing ant -p 1) Case of target and target-group mixed project help will display something like :*Available target :* compile -- compile the current projet compile-java -- compile java classes on the current project package -- package the current project package-jar -- package this project as a jar 2) Case when target and target-group are separated *Available target-group :* compile-java -- compile java classes on the current project package-jar -- package this project as a jar *Available target :* compile -- compile the current projet package -- package the current project Regards Jean Louis
Re: target-group committed
On 2008-11-19, Jean-Louis BOUDART [EMAIL PROTECTED] wrote: I just have two questions : I knew I didn't reproduce all of EasyAnt's patch 8-) - Does prefix of import / include make sense on target-group? Or should we consider target-group as an abstract target that is never prefixed? To me target-groups should be treated just like targets by import and include so I made the same prefix rules apply. Why would you want to have different rules? Wouldn't that defeat the purpose of include? - When displaying projecthelp should we have target and target-group mixed? or should we have a distinction? From the user's (the one running the build not writing the build file) there shouldn't really be any difference so I wouldn't report them separately. That may be just me. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
