Well, the title of this mail is referencing [1], as announced I was thinking that we should, but after gathering my ideas and writing this email, I am not so sure.
So was introduced lately the concept of target group in Ant. I found it quite interesting as it would help writing sharable ant script, just as it is used in EasyAnt. I have a "build system" to maintain, shared between several different kind of project, simple java ones, webapp ones, flex app ones, flex lib ones, webservice ones, etc... All of these projects share the same release process and dependency management (Ivy of course ;) ). So I have a common-build.xml, a common-build-java.xml, a common-build-webapp.xml, a common-build-flex, etc... There is some sort of inheritance between those build scripts: common-build-java.xml depends on common-build.xml, common-build-webapp.xml depends on common-build.java, etc... I have a "dist" target in common-build which expect things to be build before being published with Ivy. Then in common-build-java I have targets to build jars, and "dist" is overridden so "dist" depends on the targets that build jars: <target name="dist" depends="jar,sources,common-build.dist" /> In common-build-webapp "dist" is overridden so it depends on the target that build a war. In common-build-flex "dist" is overridden so it depends on the target that build a swf. And here comes the trouble: multi "inheritance" doesn't work well. If I have a webapp project that require some flex to be build, here comes the mess. Depending of the order of import of common-build-webapp.xml and common-build-flex.xml, either the flex will be published, either the war. I have to override "dist" in the project's build.xml so it explicitly call the build of the java, the swc and the war. Here would help target group. If I define "dist" a target group, everything will then work fine. And I think that attaching a target to a target group is a way more proper than overriding targets, as it doesn't change any dependency declared between targets in common-build, it just adds new ones. If I focus on seeing an Ant build script as a DAG (direct acyclic graph), properly overriding a DAG seems to me just adding new edges and targets, not changing them. And many overriding (which we can see as multi inheritance) can apply without interacting. Adding targets to the dependency of another target (as target groups do) seems to be the way to go. But using target groups expect me to know which part of the common-build can be extended. And I got every day some new need on some project that require a specific move in the common-build workflow. On the other hand, if I today look closely to the 2200 lines of the common build files I maintain, I have very few targets that I need to be changed as a target group. And for most of them, they are already empty of tasks. The actual heavy customization required by some project, are done in the project itself. In the project itself I don't need to care about reusability or extension, so target overriding is fine. To conclude, I don't know if opening up targets dependency can be that useful, I don't know if there is real use case where you want a spaghetti of target dependencies to be opened to a third party. Maybe it is better to explicit where target dependencies can be injected by using a special element, the target groups. Now thinking loud, maybe a simple attribute on target like dependencies="public" would also fit ? Nicolas [1] http://old.nabble.com/Maybe-we-should-open-up-%22depends%22-for-all-targets-p20603861.html --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
