AW: svn commit: r893073 - in /ant/core/trunk/docs/manual: conceptstypeslist.html targets.html using.html usinglist.html
Added: ant/core/trunk/docs/manual/targets.html + + pTargets can depend on other targets and Ant ensures that these +other targets have been executed before the current target. For +example you might have a target for compiling, for example, and a I deleted the 2nd example. + pIt is a good practice to place +your a href=CoreTasks/tstamp.htmltstamp/a tasks in a +so-called iinitialization/i target, on which all other targets +depend. Make sure that target is always the first one in the +depends list of the other targets. In this manual, most +initialization targets have the +name codequot;initquot;/code./p What about constructs like projecttstamp/ ? + pA target name can be any alphanumeric string valid in the +encoding of the XML file. The empty string quot;quot; is in this +set, as is comma quot;,quot; and space quot; quot;. Please +avoid using these, as they will not be supported in future Ant +versions because of all the confusion they cause. IDE support of +unusual target names, or any target name containing spaces, varies +with the IDE./p Added a word about blank on commandline. + pTargets beginning with a hyphen such +as codequot;-restartquot;/code are valid, and can be used to +name targets that should not be called directly from the command +line./p Added a word about hyphen on commandline. Nice description. I am not familiar with that part of the codebase, but it sounds good. Should we add call graphs? 1) For the first example (simple targets A..D) A--B--C--D 2) conditional target myTarget.check -- maybe(myTarget) 3) target group create-directory-layout -- 'empty slot' -- compile create-directory-layout -- generate-sources -- compile Jan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Naming of target-group
On Mon, 21 Dec 2009 14:00:53 -0500, Sandu Turcan atur...@gmail.com wrote: On the other hand the term extension point sounds generic and appears to accept anything the system operates on, like tasks, types, targets, dependencies etc. In this case we're only talking about targets. I think a more explicit term that has the word target in it would work better. Well, the main use case I see of target groups is about using them between different build scripts, as also noted in the documentation Stefan just wrote. So the extension point is more an extension point of the build script, more than a extension point of a particular target. So finally I quite like it. extension point cannot make me not think about Eclipse's ones. In Eclipse the extender is called the extension, and the extended is called the extension point. So I am +1 for extension-point in replacement of target-group. And for the attribute on the target I would suggest extensionOf. Nicolas On Mon, Dec 21, 2009 at 9:59 AM, Matt Benson gudnabr...@gmail.com wrote: On Dec 20, 2009, at 11:10 PM, Stefan Bodewig wrote: On 2009-12-19, Gilles Scokart gscok...@gmail.com wrote: But still I would take the risk to turn this thread into a brainstorming : absolutely. What about extension-point ? Sounds good. I don't think I weighed in on extension-point yet, but I like it as well. It's very direct as to its meaning and yet doesn't make assumptions about the buildfile's structure the way e.g. phase does. -Matt Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: svn commit: r893073 - in /ant/core/trunk/docs/manual: conceptstypeslist.html targets.html using.html usinglist.html
On 2009-12-22, jan.mate...@rzf.fin-nrw.de wrote: Added: ant/core/trunk/docs/manual/targets.html pTargets can depend on other targets and Ant ensures that these other targets have been executed before the current target. For example you might have a target for compiling, for example, and a I deleted the 2nd example. This was a verbatim copy of the existing docs from using.html 8-) What about constructs like projecttstamp/ ? same as above pTargets beginning with a hyphen such as codequot;-restartquot;/code are valid, and can be used to name targets that should not be called directly from the command line./p Added a word about hyphen on commandline. ditto Should we add call graphs? Sure, why not. Thanks Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [RESULT] Accept Groovy-Front Donation
On 2009-12-18, Stefan Bodewig bode...@apache.org wrote: The Incubator IP-CLEARANCE process has entered its final stage, I've closed the vote (no responses at all) at the incubator, it has passed. Nicolas, feel free to import the Groovy-Front into the sandbox whenever you feel like it. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Tentative 1.8.0 Release Proposal
On 2009-12-18, Stefan Bodewig bode...@apache.org wrote: If I'd be the one to create the release, I'll need some help by Kev and/or Antoine to become able to compile the optional tasks with commercial dependencies. That being said, if Antoine wants to take things over, I'll happily let him do so. Even though Antoine shared all necessary jars with me, he'll take over as a release manager for this release because I'll be without a working JDK 1.4 installation for the next two weeks. I hope to be available for subsequent releases. * decide on a name for target-group: Dec 22 are we there yet? * build 1.8.0 RC1 and call for a vote on it: Dec 23 I'll leave the concrete steps and dates to Antoine. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Tentative 1.8.0 Release Proposal
resending a mail which was considered spam by the ezmlm program Stefan Bodewig wrote: On 2009-12-18, Stefan Bodewig bode...@apache.org wrote: If I'd be the one to create the release, I'll need some help by Kev and/or Antoine to become able to compile the optional tasks with commercial dependencies. That being said, if Antoine wants to take things over, I'll happily let him do so. Even though Antoine shared all necessary jars with me, he'll take over as a release manager for this release because I'll be without a working JDK 1.4 installation for the next two weeks. I hope to be available for subsequent releases. * decide on a name for target-group: Dec 22 are we there yet? I think we need a vote. This wil delay the RC1 because we need to wait until the vote results can be proclaimed (one week). If we vote, I suggest the alternative be : target-group/group extension-point/extensionOf * build 1.8.0 RC1 and call for a vote on it: Dec 23 I'll leave the concrete steps and dates to Antoine. Stefan Regards, Antoine - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Tentative 1.8.0 Release Proposal
Stefan Bodewig wrote: On 2009-12-18, Stefan Bodewig bode...@apache.org wrote: If I'd be the one to create the release, I'll need some help by Kev and/or Antoine to become able to compile the optional tasks with commercial dependencies. That being said, if Antoine wants to take things over, I'll happily let him do so. Even though Antoine shared all necessary jars with me, he'll take over as a release manager for this release because I'll be without a working JDK 1.4 installation for the next two weeks. I hope to be available for subsequent releases. * decide on a name for target-group: Dec 22 are we there yet? * build 1.8.0 RC1 and call for a vote on it: Dec 23 I'd better make sure all my funtest stuff is documented then, hadn't I - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[VOTE] name for target-group
Hi, I would like to start a formal vote on the name of target-group. [ ] target-group name=foo/ for the group and target group=foo ... for the members of the group this is the current codebase [ ] extension-point name=foo/ for the group and target extensionOf=foo ... for members of the group [ ] others Regards, Antoine - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] name for target-group
Antoine Levy Lambert wrote: [ x] target-group name=foo/ for the group and target group=foo ... for the members of the group this is the current codebase Let me start with +1 for the current codebase. Antoine - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] name for target-group
[ x] extension-point name=foo/ for the group and target extensionOf=foo ... for members of the group or as an alternative [ x] target-interface name=foo/ for the group and target implements=foo ... for the members of the group 2009/12/22 Antoine Levy Lambert anto...@gmx.de Antoine Levy Lambert wrote: [ x] target-group name=foo/ for the group and target group=foo ... for the members of the group this is the current codebase Let me start with +1 for the current codebase. Antoine - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org
Re: Tentative 1.8.0 Release Proposal
On 2009-12-22, Steve Loughran ste...@apache.org wrote: I'd better make sure all my funtest stuff is documented then, hadn't I If you want it as part of 1.8.0, yes, better hurry up. I have removed it from defaults.properties, BTW. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Maybe we should open up depends for all targets [again]
You're right. Initially in EasyAnt we wanted to find a way to define lifecycles. A lifecycle is composed by a sequence of generic steps (what we've called phase). Then we could play with additional script (plugins) that can be bind to a phase. Again the idea was to make genericity in our build scripts. So suppose we have a target that does the java-compilation (bind to compile phase), another one that does the jar-packaging (bind to package phase) etc... Now suppose we want to build a webapp the only thing that will differ with my previous exemple is the target that package the war (which can be bind to package phase). As a end user we will still have the common lifecycle with all our steps (phase) like compile, package etc... in any context (standar java application, webapp etc...) Since our use case was really similar with maven phases we decided to use the same name. Now i think it can be limitting to integrate it in ant with that name(phase), that's why when this feature was introduced in ant's trunk, someone suggested to call it target-group. By the way there is still a main difference between a target-group and a phase. A phase is never prefixed whereas a target-group can be prefixed depending on how you import/include it. Again if we consider target-group is JUST a way to have target dependency injection, this doesn't make sense. In opposite if we consider that target-groups are toplevel target(to define a lifecycle for exemple), 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 (containing our lifecycle) 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. Using phase (a target-group never prefixed), it is possible in a buildscript to assign a target to a phase which is not declared in the current build script. It makes the buildscript dependent on the caller to declare the phase prior to the use call, and as such becomes a requirement of the buildscript. Considering that this was a use case really related to easyant, we've made our own implementation of phase inspired by target-group current code base. This means we have our own ProjectHelper so we will not be really affected by any change the naming of target-group. Hope this will help the discution. Cheers, Le 16 décembre 2009 14:12, Nicolas Lalevée nicolas.lale...@hibnet.org a écrit : On Sat, 12 Dec 2009 13:03:45 +0100, Jean-Louis Boudart jeanlouis.boud...@gmail.com wrote: How about: target-inteface name=foo/ target name=bar implements=foo/ /me run and hides! 2009/12/12 Nicolas Lalevée nicolas.lale...@hibnet.org On Fri, 11 Dec 2009 11:51:30 -0600, Dominique Devienne ddevie...@gmail.com wrote: On Fri, Dec 11, 2009 at 6:32 AM, Xavier Hanin xavier.ha...@gmail.com wrote: 2009/12/10 Stefan Bodewig bode...@apache.org and would do away with any notion of target composition people way expect from the name target-*group*. I also think the name target-group is confusing for something that doesn't provide any composition. [...] What do you think this: target name=foo dependencies=open/ target name=bar join-depends=foo/ Like in a SQL join you mean? ;) But I'm not good at finding names, so maybe I should just go back to my work :-) Frankly I think the Maven terminology of a goal is appropriate here. The fact that a goal is implemented as a target that has no tasks is an impl detail. I think it easier that a goal is a higher level abstraction that the target, and that target can choose to participate into one and only one goal. Whether goals themselves should only depend on goals might be a good idea. Goals would define the abstract interface to the build system and logic, and targets become its implementation. As I wrote, a target can belong to only a single goal, but can depend on targets or goals, as long as the DAG is acyclic. I think that abstract interface target and implementation target seems to fit very well into my use case I presented earlier. It was about a build script expecting some target implementation to be run before some other; expecting
Re: [VOTE] name for target-group
On 2009-12-22, Antoine Levy Lambert anto...@gmx.de wrote: I would like to start a formal vote on the name of target-group. Currently I don't have strong feelings either way, I prefer extension-point slightly, but can certainly live with target-group. I'll go with the majority. [ ] target-group name=foo/ for the group and target group=foo ... for the members of the group this is the current codebase As Antoine pointed out in an off-list email to me, this is not the current code base since I made an error when writing the docs. The attribute on target in the current codebase is named target-group, not group. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AW: svn commit: r893210 - /ant/core/trunk/docs/manual/targets.html
Thanks Jesse Jan URL: http://svn.apache.org/viewvc?rev=893210view=rev Log: Typo. -tasks direclty under the project tag (since Ant 1.6.0):/p +tasks directly under the project tag (since Ant 1.6.0):/p blockquotepre - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
