You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Niklas Matthies <ml...@nmhq.net> on 2010/08/18 00:35:10 UTC
Conditional target problem
We have something like the following (target bodies omitted):
<target name="checkout-sources" depends="other stuff">
<!-- takes several minutes -->
<target name="determine-release-number"
depends="checkout-sources" unless="release.number">
<!-- determines release.number from sources -->
<target name="target1" depends="determine-release-number">
<!-- needs release.number -->
<target name="target2" depends="checkout-sources, target1">
<!-- needs sources and target1 -->
The problem: "ant -Drelease.number=... target1" causes
checkout-sources (and its dependencies) to be executed although there
is no need for it, as release.number is already defined.
We can't put the unless="release.number" on checkout-sources (and its
dependencies) because it would break target2 when release.number is
predefined.
We can't make checkout-sources a macro (called both by target2 and by
determine-release-number) because of all its dependencies, and also
because an up-to-date check on it is highly non-trivial, so in the
target2 case it might end up being executed twice.
We _could_ duplicate the body and the dependencies of checkout-sources
into determine-release-number (and remove the latter's dependency on
checkout-sources), but I'd have to do that for quite a number of the
dependencies as well, as they contribute to the expensiveness of
checkout-sources. The result would be a lot of redundancy, effectively
duplicating a dependency subgraph.
Is there a way to solve the problem, within a single Ant instance,
without creating redundancies?
-- Niklas Matthies
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
AW: Conditional target problem
Posted by "Knuplesch, Juergen" <Ju...@icongmbh.de>.
I use the <if> from ant-contrib combined with antcall or antcallback to have more flexibility on calling targets.
I use properties like ${nocvs} to not use CVS, even when the target is executed (again using <if> or unless)
I have unless properties for CVS, junit, javadoc, compile .....
In your case:
<target name="checkout-sources" depends="other stuff" unless="nocvs">
<!-- takes several minutes -->
In "other stuff" you have to introduce other unless properties probably.
Now you run
ant -Drelease.number=... -Dnocvs=true target1"
whil you run target2 this way
ant -Drelease.number=... target2"
-----Ursprüngliche Nachricht-----
Von: Niklas Matthies [mailto:ml_ant-user@nmhq.net]
Gesendet: Mittwoch, 18. August 2010 00:35
An: user@ant.apache.org
Betreff: Conditional target problem
We have something like the following (target bodies omitted):
<target name="checkout-sources" depends="other stuff">
<!-- takes several minutes -->
<target name="determine-release-number"
depends="checkout-sources" unless="release.number">
<!-- determines release.number from sources -->
<target name="target1" depends="determine-release-number">
<!-- needs release.number -->
<target name="target2" depends="checkout-sources, target1">
<!-- needs sources and target1 -->
The problem: "ant -Drelease.number=... target1" causes
checkout-sources (and its dependencies) to be executed although there
is no need for it, as release.number is already defined.
We can't put the unless="release.number" on checkout-sources (and its
dependencies) because it would break target2 when release.number is
predefined.
We can't make checkout-sources a macro (called both by target2 and by
determine-release-number) because of all its dependencies, and also
because an up-to-date check on it is highly non-trivial, so in the
target2 case it might end up being executed twice.
We _could_ duplicate the body and the dependencies of checkout-sources
into determine-release-number (and remove the latter's dependency on
checkout-sources), but I'd have to do that for quite a number of the
dependencies as well, as they contribute to the expensiveness of
checkout-sources. The result would be a lot of redundancy, effectively
duplicating a dependency subgraph.
Is there a way to solve the problem, within a single Ant instance,
without creating redundancies?
-- Niklas Matthies
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: Conditional target problem
Posted by Niklas Matthies <ml...@nmhq.net>.
I filed an enhancement request related to this topic:
http://issues.apache.org/bugzilla/show_bug.cgi?id=49776
-- Niklas Matthies
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: AW: Conditional target problem
Posted by Niklas Matthies <ml...@nmhq.net>.
On Thu 2010-08-19 at 09:59h, Vimil Saju wrote on user:
> I read about the new macrodef task which can be used create a custom
> composite task by combining other tasks together. Using the macrodef
> task instead of antcall cant we overcome the performance overhead
> and the property visibility issues with antcall?
You lose Ant's target dependency management once you're in a macrodef.
Without that dependency management, you might as well use some
scripting language (with more human-friendly syntax than XML ;))
instead of Ant.
-- Niklas Matthies
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: AW: Conditional target problem
Posted by Matt Benson <gu...@gmail.com>.
On Aug 19, 2010, at 11:59 AM, Vimil Saju wrote:
> I read about the new macrodef task which can be used create a custom composite task by combining other tasks together. Using the macrodef task instead of antcall cant we overcome the performance overhead and the property visibility issues with antcall?
>
Certainly, aside from the fact that macrodef is not really that new, having been released with Ant 1.6 IIRC. ;)
-Matt
> --- On Thu, 8/19/10, Knuplesch, Juergen <Ju...@icongmbh.de> wrote:
>
> From: Knuplesch, Juergen <Ju...@icongmbh.de>
> Subject: AW: Conditional target problem
> To: "Ant Users List" <us...@ant.apache.org>
> Date: Thursday, August 19, 2010, 8:03 AM
>
> Antcallback gives back some props you define
>
> -----Ursprüngliche Nachricht-----
> Von: Niklas Matthies [mailto:ml_ant-user@nmhq.net]
> Gesendet: Mittwoch, 18. August 2010 15:55
> An: Ant Users List
> Betreff: Re: Conditional target problem
>
> On Tue 2010-08-17 at 16:20h, Vimil Saju wrote on user:
>> I know ant is supposed to be declarative language as opposed to a
>> procedural one, but whats wrong with using the 'if' task provided
>> with ant-contrib along with "ant-call" task?
>
> AntCall effectively creates a new Ant instance. Properties and
> references set within the call won't be visible after the call
> returns, and targets executed before the call might be executed
> again within the call. It's very different from having a target
> as a dependency. Replacing one with the other has all sorts of
> ramifications.
>
> -- Niklas Matthies
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: AW: Conditional target problem
Posted by Vimil Saju <vi...@yahoo.com>.
I read about the new macrodef task which can be used create a custom composite task by combining other tasks together. Using the macrodef task instead of antcall cant we overcome the performance overhead and the property visibility issues with antcall?
--- On Thu, 8/19/10, Knuplesch, Juergen <Ju...@icongmbh.de> wrote:
From: Knuplesch, Juergen <Ju...@icongmbh.de>
Subject: AW: Conditional target problem
To: "Ant Users List" <us...@ant.apache.org>
Date: Thursday, August 19, 2010, 8:03 AM
Antcallback gives back some props you define
-----Ursprüngliche Nachricht-----
Von: Niklas Matthies [mailto:ml_ant-user@nmhq.net]
Gesendet: Mittwoch, 18. August 2010 15:55
An: Ant Users List
Betreff: Re: Conditional target problem
On Tue 2010-08-17 at 16:20h, Vimil Saju wrote on user:
> I know ant is supposed to be declarative language as opposed to a
> procedural one, but whats wrong with using the 'if' task provided
> with ant-contrib along with "ant-call" task?
AntCall effectively creates a new Ant instance. Properties and
references set within the call won't be visible after the call
returns, and targets executed before the call might be executed
again within the call. It's very different from having a target
as a dependency. Replacing one with the other has all sorts of
ramifications.
-- Niklas Matthies
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
AW: Conditional target problem
Posted by "Knuplesch, Juergen" <Ju...@icongmbh.de>.
Antcallback gives back some props you define
-----Ursprüngliche Nachricht-----
Von: Niklas Matthies [mailto:ml_ant-user@nmhq.net]
Gesendet: Mittwoch, 18. August 2010 15:55
An: Ant Users List
Betreff: Re: Conditional target problem
On Tue 2010-08-17 at 16:20h, Vimil Saju wrote on user:
> I know ant is supposed to be declarative language as opposed to a
> procedural one, but whats wrong with using the 'if' task provided
> with ant-contrib along with "ant-call" task?
AntCall effectively creates a new Ant instance. Properties and
references set within the call won't be visible after the call
returns, and targets executed before the call might be executed
again within the call. It's very different from having a target
as a dependency. Replacing one with the other has all sorts of
ramifications.
-- Niklas Matthies
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: Conditional target problem
Posted by Niklas Matthies <ml...@nmhq.net>.
On Tue 2010-08-17 at 16:20h, Vimil Saju wrote on user:
> I know ant is supposed to be declarative language as opposed to a
> procedural one, but whats wrong with using the 'if' task provided
> with ant-contrib along with "ant-call" task?
AntCall effectively creates a new Ant instance. Properties and
references set within the call won't be visible after the call
returns, and targets executed before the call might be executed
again within the call. It's very different from having a target
as a dependency. Replacing one with the other has all sorts of
ramifications.
-- Niklas Matthies
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: Conditional target problem
Posted by Vimil Saju <vi...@yahoo.com>.
I know ant is supposed to be follow a declarative style rather than a procedural style. But what is wrong with writing scripts using the 'if' task in conjunction with the ant-call task?
like the below example
<target name="determine-release-number"<if> <not> <isset property="release.number"/> </not> <then> <ant-call target="checkout-sources"/> </then> </if>
--- On Tue, 8/17/10, Vimil Saju <vi...@yahoo.com> wrote:
From: Vimil Saju <vi...@yahoo.com>
Subject: Re: Conditional target problem
To: "Ant Users List" <us...@ant.apache.org>
Date: Tuesday, August 17, 2010, 4:20 PM
I know ant is supposed to be declarative language as opposed to a procedural one, but whats wrong with using the 'if' task provided with ant-contrib along with "ant-call" task? Wont it make ant-scripts more readable
something like this
<if>
--- On Tue, 8/17/10, Niklas Matthies <ml...@nmhq.net> wrote:
From: Niklas Matthies <ml...@nmhq.net>
Subject: Conditional target problem
To: user@ant.apache.org
Date: Tuesday, August 17, 2010, 3:35 PM
We have something like the following (target bodies omitted):
<target name="checkout-sources" depends="other stuff">
<!-- takes several minutes -->
<target name="determine-release-number"
depends="checkout-sources" unless="release.number">
<!-- determines release.number from sources -->
<target name="target1" depends="determine-release-number">
<!-- needs release.number -->
<target name="target2" depends="checkout-sources, target1">
<!-- needs sources and target1 -->
The problem: "ant -Drelease.number=... target1" causes
checkout-sources (and its dependencies) to be executed although there
is no need for it, as release.number is already defined.
We can't put the unless="release.number" on checkout-sources (and its
dependencies) because it would break target2 when release.number is
predefined.
We can't make checkout-sources a macro (called both by target2 and by
determine-release-number) because of all its dependencies, and also
because an up-to-date check on it is highly non-trivial, so in the
target2 case it might end up being executed twice.
We _could_ duplicate the body and the dependencies of checkout-sources
into determine-release-number (and remove the latter's dependency on
checkout-sources), but I'd have to do that for quite a number of the
dependencies as well, as they contribute to the expensiveness of
checkout-sources. The result would be a lot of redundancy, effectively
duplicating a dependency subgraph.
Is there a way to solve the problem, within a single Ant instance,
without creating redundancies?
-- Niklas Matthies
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: Conditional target problem
Posted by Vimil Saju <vi...@yahoo.com>.
I know ant is supposed to be declarative language as opposed to a procedural one, but whats wrong with using the 'if' task provided with ant-contrib along with "ant-call" task? Wont it make ant-scripts more readable
something like this
<if>
--- On Tue, 8/17/10, Niklas Matthies <ml...@nmhq.net> wrote:
From: Niklas Matthies <ml...@nmhq.net>
Subject: Conditional target problem
To: user@ant.apache.org
Date: Tuesday, August 17, 2010, 3:35 PM
We have something like the following (target bodies omitted):
<target name="checkout-sources" depends="other stuff">
<!-- takes several minutes -->
<target name="determine-release-number"
depends="checkout-sources" unless="release.number">
<!-- determines release.number from sources -->
<target name="target1" depends="determine-release-number">
<!-- needs release.number -->
<target name="target2" depends="checkout-sources, target1">
<!-- needs sources and target1 -->
The problem: "ant -Drelease.number=... target1" causes
checkout-sources (and its dependencies) to be executed although there
is no need for it, as release.number is already defined.
We can't put the unless="release.number" on checkout-sources (and its
dependencies) because it would break target2 when release.number is
predefined.
We can't make checkout-sources a macro (called both by target2 and by
determine-release-number) because of all its dependencies, and also
because an up-to-date check on it is highly non-trivial, so in the
target2 case it might end up being executed twice.
We _could_ duplicate the body and the dependencies of checkout-sources
into determine-release-number (and remove the latter's dependency on
checkout-sources), but I'd have to do that for quite a number of the
dependencies as well, as they contribute to the expensiveness of
checkout-sources. The result would be a lot of redundancy, effectively
duplicating a dependency subgraph.
Is there a way to solve the problem, within a single Ant instance,
without creating redundancies?
-- Niklas Matthies
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org