ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "didge" <di...@foundrylogic.com>
Subject RE: <antexec>
Date Thu, 06 Feb 2003 18:32:20 GMT
> But then, the principal goal of <antcall> is to be able to override some
> properties, so the target ant-called can do something else than it did the
> first time. By using <antexec>, you cannot overwrite properties, so cannot
> parameterize the called target.

With <antexec>, the project is shared between the caller and the callee, so
in effect, the caller is parameterized by the current project.  But, since
properties are immutable, all callees see the same set of property values,
except those properties added between <antexec>s.

Another interesting side effect is that the called target can add properties
to the caller, so to speak, since they both share the same project instance,
as if it were put in a depends clause.

> Your <antexec> or Centipede <call> do make build faster, but not
> safer.

Virtually no task in ant can prevent the user from hosing themselves.  But
seriously, what does 'safe' mean?  <delete>, if configured incorrectly,
could clean your file system for you.  That doesn't sound 'safe' but it sure
is a valuable task that I couldn't do without.  The build author simply has
to take responsibility for the correct configuration of his or her build.

> The right approach would be to make <antcall> lean and mean, by for
> example not
> reparsing the build file, and Costin's made some progress in that regard.
> Also not having the copy too much state from the parent Project
> to the child
> Project would be good (by having additional/overridden state in the child
> take priority over the Parent state).

Velocity has a similar concept in its contexts.  Contexts nest, and set
values are made only to outer most context, but get of a property causes a
search of the contexts recursively until the first matching property is
found.

I think that if this idea were implemented, <antexec> would still have some
general value, for example, if you actually _want_ to have the called target
to set properties for the caller, as an alternative to listing the called
target in a depends attribute.

Anyway, until <antcall> gets a needed boost, I'm going to keep playing with
<antexec> to see if any other issues or benefits materialize.

didge

> -----Original Message-----
> From: Dominique Devienne [mailto:DDevienne@lgc.com]
> Sent: Thursday, February 06, 2003 7:38 AM
> To: 'Ant Users List'
> Subject: RE: <antexec>
>
>
> I'll take that back. <antcall> is also affected by cycles, leading to an
> infinite loop between aTarget and bTarget (ends up in a
> StackOverflowError).
>
> But then, the principal goal of <antcall> is to be able to override some
> properties, so the target ant-called can do something else than it did the
> first time. By using <antexec>, you cannot overwrite properties, so cannot
> parameterize the called target.
>
> I think I'm missing something here. --DD
>
> -----Original Message-----
> From: Dominique Devienne [mailto:DDevienne@lgc.com]
> Sent: Thursday, February 06, 2003 8:54 AM
> To: 'Ant Users List'
> Subject: RE: <antexec>
>
> Yes, Centipede as one I believe. The reason it's not in Ant is that it
> throws off the checks for circular dependencies between targets. Simply
> consider:
>
> 	<target name="aTarget">
> 		<antexec target="bTarget"/>
> 	</target>
>
> 	<target name="bTarget">
> 		<antexec target="aTarget"/>
> 	</target>
>
> Your <antexec> or Centipede <call> do make build faster, but not
> safer. The
> right approach would be to make <antcall> lean and mean, by for
> example not
> reparsing the build file, and Costin's made some progress in that regard.
> Also not having the copy too much state from the parent Project
> to the child
> Project would be good (by having additional/overridden state in the child
> take priority over the Parent state).
>
> So in short, it's all up to you to decide what is important to you! Every
> situation is different of course; by the more I learn about Ant,
> the less I
> need to rely on <antcall> for my own builds...
>
> Does this help? --DD
>
> -----Original Message-----
> From: didge [mailto:didge@foundrylogic.com]
> Sent: Wednesday, February 05, 2003 6:57 PM
> To: Ant Users List
> Subject: <antexec>
>
> Has anyone written a Task that would be to CallTarget as exec is
> to fork in
> unix?  That is, unlike CallTarget which essentially re-inits the project,
> 'ExecTarget' would simply execute the named target.  I can't find anything
> like it in the ant 1.5.1 source or in my internet searching.
>
> For example:
>
> 	<target name="aTarget">
> 		...
> 	</target>
>
> 	<target name="bTarget">
> 		<antexec target="aTarget"/>
> 	</target>
>
> In my projects, I have some deeply nested <antcall>s and I was shocked at
> how much faster my build ran when I used this ExecTarget implementation
> instead:
>
> import org.apache.tools.ant.*;
>
> /**
>  * Exec another target in the same project.
>  *
>  *  <pre>
>  *    &lt;target name="foo"&gt;
>  *      &lt;antexec target="bar" /&gt;
>  *    &lt;/target&gt;
>  *
>  *    &lt;target name="bar" depends="init"&gt;
>  *      ...
>  *    &lt;/target&gt;
>  * </pre>
>  *
>  *
>  * @author <a href="mailto:didge@foundrylogic.com">didge</a>
>  *
>  * @ant.task name="antexec" category="control"
>  */
> public class ExecTarget extends Task {
>     private String target;
>
>     public String getTarget() {
>         return target;
>     }
>
>     public void setTarget(String target) {
>         this.target = target;
>     }
>
>     public void execute() throws BuildException {
>         project.executeTarget(target);
>     }
> }
>
> Are there any reasons why I wouldn't want to do this, assuming that I want
> to be able to side affect my project and I don't want the overhead of
> re-init'ing?
>
>
> Dave Masser-Frye
> didge@foundrylogic.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ant-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: ant-user-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ant-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: ant-user-help@jakarta.apache.org
>
>


Mime
View raw message