ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <>
Subject Maybe we should open up "depends" for all targets [again]
Date Wed, 09 Dec 2009 21:35:06 GMT
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, 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

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 ?



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message