ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: [VOTE] Ant/Antcall Returning properties and references [WAS]Re: ant 1.5.4 : Import
Date Thu, 28 Aug 2003 17:11:01 GMT
> From: Steve Loughran [] 
> Antoine Levy-Lambert wrote:
> > So far, I have got two +1 (myself and Jan Materne) for this 
> proposal. 
> > The vote will be closed tomorrow at 12:28 pm CET (20 hours 
> from now). 
> > Three +1s are required for a code change, so, by the likes 
> of it, the 
> > vote will have a negative result.
> > 
> > The <antfetch/>, <antcallback/>, <call/> tasks of Antelope provide

> > functionality in terms of returning properties. This 
> <antreturn/> is 
> > also returning references, so it can bring something new, plus the 
> > ease for users who want to deploy ant, but no extra jars providing 
> > core functionality to ant.
> > 
> > Since there are already tons of changes in ant 1.6 alpha, 
> there can be 
> > some wisdom in refusing or postponing this change.
> > 
> I'm kind of neutral on the idea. I can see it has its uses, 
> but can also 
> see it as kind of dangerous. It is nowhere near as controlled 
> a return 
> mechanism as, say, a method call where unless global variables are 
> changed, the return parameters get stuck in properties of the callers 
> choice, not the callees.

I have to say that I do have uses for this kind of thing, but I agree
that the implementation of this feature should give control to the
caller on the naming of the properties being returned. 

A suggestion on that regard would be adding a "prefix" attribute to
<antreturn/> so that the properties get set on a separate "namespace"
and after that the caller can copy the values around as they see fit.
Alternatively, each individual property being returned should have a
"property" or "reference" attribute to indicate the location in which to
put it.

I think the "prefix" solution is less intrusive and we have used it
when reading properties from the environment.

As per cases when you need this, I have today a large buildfile that
with things like managing CVS operations, one of the things that it
how to do is to identify the current-branch one is working on.
Now this is a large file and I really do not want to mix it (import)
the buildfile for compiling the code. However, when we build a binary
I would like to include information about the current-branch and such.
I do not want to have multiple versions of the code, I would prefer
being able to obtain this information by simply doing an <antreturn> or
something like that. It is much more cleaner than <importing> and giving
access in the build file to a bunch of things that where not intended.

Jose Alberto

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

View raw message