> > > 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-sources generate any source code for inclusion in compilation integration-test process 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-test perform 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 test run tests using a suitable unit testing framework. These tests should not require the code be packaged or deployed test-compile compile 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-sources process the test source code, for example to filter any values test-provision supply provision required to test this project validate validate 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-lib clean 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 as a JAR source:test package test source as a JAR test/skip skip tests In this example there is more target-group than "public" target but this could give you an idea of WHY i don't want to have targets and phase mixed :) Maybe this i more pertinent to be in EasyAnt instead of ant-core, but i think we should consider it :p > > > > 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. What do you think about this? :p
