>> > > 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"> >> <echo>javadoc</echo> >> </target> >> ... >> </project> >> >> b.xml >> <project name="B"> >> <target name="junitreport" target-group="report" >description="generate >> junit >> report"> >> <echo>junitreport</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]
