ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Re: Maybe we should open up "depends" for all targets [again]
Date Thu, 10 Dec 2009 16:15:50 GMT
On 2009-12-09, Nicolas Lalevée <nicolas.lalevee@hibnet.org> wrote:

> Well, the title of this mail is referencing [1],

The short summary: it was discussed whether target-groups should be
allowed to contain tasks.  I then mused whether we should do away with
target-group completely and make target's depend attribute extensible
just like the one of current target-group is.

> 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.

Yes.  I think this is the exact reason for target-groups.  <import>'s
target overriding doesn't work well and it is a lot easier to inject
your own targets into depends lists than to override existing targets
and ensure you get the original depends lists right.

> But using target groups expect me to know which part of the
> common-build can be extended.

It takes planning 8-)

> To conclude, I don't know if opening up targets dependency can be that
> useful,

I think your post makes a point that there are targets that are designed
to be extended and others that are not.  If we removed the target-group
and made all depends lists modifiable, we'd lose a way to signal which
targets are to be extended and which not (not that we had such a
mechanism before target-group was introduced).

> Now thinking loud, maybe a simple attribute on target like
> dependencies="public" would also fit ?

Likely coupled with changing the current target-group name.

Only thinking loudly as well we could turn

<target-group name="foo"/>
<target name="bar" target-group="foo"/>

into

<target name="foo" dependencies="public"/>
<target name="bar" before-targets="foo"/>

and would do away with any notion of target composition people way
expect from the name target-*group*.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message