Re: AntXtras + Ant 1.8 (unhappy duo apparently)
On 2008-11-22, Wascally Wabbit [EMAIL PROTECTED] wrote: I'll start doing just this...juuust as soon as I figure out how to build the repository code into a binary distro ;-) http://ant.apache.org/manual/install.html#buildingant Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r720156 - in /ant/core/trunk: WHATSNEW docs/manual/CoreTasks/javadoc.html src/main/org/apache/tools/ant/taskdefs/Javadoc.java src/tests/antunit/taskdefs/javadoc-test.xml
On 2008-11-24, [EMAIL PROTECTED] wrote: URL: http://svn.apache.org/viewvc?rev=720156view=rev Log: Add attributes for javadoc's -docfilessubdirs and -excludedocfilessubdir CLI args. PR 34455 Modified: ant/core/trunk/src/tests/antunit/taskdefs/javadoc-test.xml I've disabled the tests since they fail on JDK 1.4.2 for me (they pass on Java6) and I can't figure out why. Without any special arguments javadoc is supposed to copy doc-files directories from source to dest, but on my machine it doesn't. Any ideas? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Yet an other view for target-group
On 2008-11-21, Gilles Scokart [EMAIL PROTECTED] wrote: The concept of target-group seems confusing for the moment. At least it confuses me, but I get the feeling that everybody must be seeing something that I don't - so I very much appreciate any effort to enlighten me. While I do see differences between targets and target-groups for people writing build files, I miss where they differ (or should differ) for anybody running Ant. Instead of having one special type of target to define a new concept, maybe we need 2 : target-group and target-part. With the caracteristics that : * target-group and target-part can both have depends to any target. * target-part can declare that they are part of 1 or more target-group. * target-group have no content (not sure that's require for the view that we want). Which from the end-user POV means targets and target-groups are command line callable, target-parts are not. Is that correct? Stefan - 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/
Re: Yet an other view for target-group
2008/11/24 Stefan Bodewig [EMAIL PROTECTED]: On 2008-11-21, Gilles Scokart [EMAIL PROTECTED] wrote: The concept of target-group seems confusing for the moment. At least it confuses me, but I get the feeling that everybody must be seeing something that I don't - so I very much appreciate any effort to enlighten me. While I do see differences between targets and target-groups for people writing build files, I miss where they differ (or should differ) for anybody running Ant. Instead of having one special type of target to define a new concept, maybe we need 2 : target-group and target-part. With the caracteristics that : * target-group and target-part can both have depends to any target. * target-part can declare that they are part of 1 or more target-group. * target-group have no content (not sure that's require for the view that we want). Which from the end-user POV means targets and target-groups are command line callable, target-parts are not. Is that correct? Stefan I would prefer that they could be called. I actually see a very big difference for the user running Ant. A target-group has an higher granularity. A normal user would rather use that granularity level. Only advanced users (probably the developpers who wrote the script) could still call lower level part. I would say that target-group, target-part are different level of abstraction. What part constitues the group are implementation details that should be +/- hidden for the normal user (and probably for developpers of other part of the global script). Maybe an other way to see the difference is to foccus on the relationship PartOf, instead of foccussing on the distinction target-group, target-part. I think it is easier to see a difference beween PartOf and Depends relationship. I'm not sure I clarified something... I hope I didn't add more confusion ;-) -- Gilles Scokart - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Yet an other view for target-group
Which from the end-user POV means targets and target-groups are command line callable, target-parts are not. Is that correct? Stefan I would prefer that they could be called. I think both target and target group should be command line callable. I actually see a very big difference for the user running Ant. A target-group has an higher granularity. A normal user would rather use that granularity level. Only advanced users (probably the developpers who wrote the script) could still call lower level part. I completly aggree :) I would say that target-group, target-part are different level of abstraction. What part constitues the group are implementation details that should be +/- hidden for the normal user (and probably for developpers of other part of the global script). Maybe an other way to see the difference is to foccus on the relationship PartOf, instead of foccussing on the distinction target-group, target-part. I think it is easier to see a difference beween PartOf and Depends relationship. I think it's pretty much easier to see the difference like that :) I'm not sure I clarified something... I hope I didn't add more confusion ;-) I hope so :p
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]
