Re: [VOTE] Ant/Antcall Returning properties and references [WAS] Re: ant 1.5.4 : Import
Dominique --
Dang, I didn't know there was a competition going on!
I wrote most of the Antelope tasks because I had a specific need. Feel
free to grab what you want and put it in Ant-contrib. I like your
"loophole" for your "antreturn" task, I didn't like the code reuse
either, but the way the "ant" task was written didn't lend itself to
extension, and I didn't see your loophole.
Really, the "call" task in Antelope does what many people seem to
expect, and is a very minimal task with almost no overhead. Below is the
complete source. Judging from the e-mail I get, most people are
downloading the Antelope tasks for this "call" task, the
"try/catch/finally" task, the "if/else" task, and the "post" task.
Ant-contrib already has try/catch and if/else, but adding call and post
(or equivalent) would be good.
Dale
Here's the "call" task source. It's very short, even with whitespace
it's only 17 lines. "Call" is to replace "antcall", not "ant".
import org.apache.tools.ant.Task;
import org.apache.tools.ant.BuildException;
public class Call extends Task {
private String target = null;
public void setTarget(String target) {
this.target = target;
}
public void execute() {
if (target == null)
throw new BuildException("target is required");
getProject().executeTarget(target);
}
}
Dominique Devienne wrote:
-Original Message-
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
I'd like to explore the needs that is driving this specific feature
request - and see whether there is a different way to meet it.
or will allow you to import a set of properties (or
property setting tasks) for example.
I probably would not have needed if I had access to ...
I feel it's a little hackish too, even though it serves my purpose just
fine for now. The fact that ProjectComponent reference instances change
Project when returned could have negative side effects for example???
Three +1s are required for a code change, so, by the likes of it,
the vote will have a negative result.
No, just no positive result.
Sorry for dropping the ball on you ;-) I posted this code kinda showing off
I guess, during the discussion if you recall, and also because it
might be useful to somebody else. I looked at the Antelope one, and really
didn't like the code duplication I saw there. So I hacked my own thanks to a
loop hope related to the Introspection rules of Ant to get a hold of the
nested private project... Would be cleaner in proper, but still not
great.
is the way to go forward I think. I'm just missing it with my 1.5.3
Ant used in production builds (augmented Ant, but not modified in any way).
Thanks for proposing my code though. Cheers, --DD
PS: Maybe Ant-Contrib would like to incorporate
to compete on features with Antelope??? ;-)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Ant/Antcall Returning properties and references [WAS] Re: ant 1.5.4 : Import
Hello, As I am not a commiter i don't may vote, but i would like to explain my point of view on this proposal. I don't think that it is a good way. because ant build file are not script file and include some returning sub project will be use as a function : this is the first foot to scripting language. I like ant because it describe the build, it does not script it. I did a lot of build with script because i had no way to do something else, and i rather not see this in ant. I like the import of antlib (snippet from build file) and the macro and preset task. In my humble opinion it is just the necessary stuff. I know that some key user in special part of special way may need this, but in 99% of case it is unlikeable. In my opinion it is better to keep the task as is, and let the returning task live in a special place but not in the ant core. Emmanuel. ps: sorry for this quiet bad english. :) - Message d'origine - De : "Antoine Levy-Lambert" <[EMAIL PROTECTED]> À : "Ant Developers List" <[EMAIL PROTECTED]> Envoyé : jeudi 28 août 2003 16:37 Objet : Re: [VOTE] Ant/Antcall Returning properties and references [WAS] Re: ant 1.5.4 : Import > 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 , , tasks of Antelope provide > functionality in terms of returning properties. This 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. > > And there is also enough work fixing small or large bugs in existing > functionality. > > Cheers, > > Antoine > - Original Message - > From: "Antoine Levy-Lambert" <[EMAIL PROTECTED]> > To: "Ant Developers List" <[EMAIL PROTECTED]> > Sent: Friday, August 22, 2003 12:28 PM > Subject: [VOTE] Ant/Antcall Returning properties and references [WAS] Re: > ant 1.5.4 : Import > > > > I think that the code of Dominique would add a lot of value to ant. > > Instead of committing the code as is, I would like simply to add the new > > features to the task. > > This means that it should be a no brainer to have these features then also > > in > > Can we vote about introducing it ? > > I start with my +1 > > Cheers, > > Antoine > > - Original Message - > > From: "Dominique Devienne" <[EMAIL PROTECTED]> > > To: "'Ant Developers List'" <[EMAIL PROTECTED]> > > Sent: Thursday, July 24, 2003 5:36 PM > > Subject: RE: ant 1.5.4 : Import > > > > > > > Then have a look at what I did in the past two days to do something > > similar > > > ;-) I created an task that piggybacks on , and allows > > > returning properties and/or references from the called build file back > > into > > > the caller's context (Project). > > > > > > That would take care of that use case ;-) --DD > > > > > > > -Original Message- > > > > From: Conor MacNeill [mailto:[EMAIL PROTECTED] > > > > Sent: Thursday, July 24, 2003 10:39 AM > > > > To: Ant Developers List > > > > Subject: Re: ant 1.5.4 : Import > > > > > > > > On Fri, 25 Jul 2003 01:23 am, Dominique Devienne wrote: > > > > > > > > > > I (strongly again ;) believe that imported build files should be > > > > designed > > > > > to be imported, and never used without being imported. > > > > > > > > I disagree (strongly :-). I think augmenting/overriding an existing > > build > > > > file > > > > is a valid use for import. I recently changed the checkstyle build I > > have > > > > been using (check.xml) to import Ant's build.xml to pick up property > > defs > > > > for > > > > various locations. Have a look. > > > > > > > > Conor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > target="set-properties"> > > > > > > > > > > > > > > > > > > > > > > > > > > > target=&quo
RE: [VOTE] Ant/Antcall Returning properties and references [WAS]Re: ant 1.5.4 : Import
> From: Steve Loughran [mailto:[EMAIL PROTECTED] > > 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 , , tasks of Antelope provide > > functionality in terms of returning properties. This > 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 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 before when reading properties from the environment. As per cases when you need this, I have today a large buildfile that deals with things like managing CVS operations, one of the things that it knows 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) with the buildfile for compiling the code. However, when we build a binary deliverable 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 or something like that. It is much more cleaner than and giving access in the build file to a bunch of things that where not intended. Jose Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Ant/Antcall Returning properties and references [WAS] Re: ant 1.5.4 : Import
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 , , tasks of Antelope provide functionality in terms of returning properties. This 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. And there is also enough work fixing small or large bugs in existing functionality. Cheers, Antoine 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. anyway, back to fixing defects in COM objects regarding string marshalling... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Ant/Antcall Returning properties and references [WAS] Re: ant 1.5.4 : Import
> -Original Message- > From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > > I'd like to explore the needs that is driving this specific feature > request - and see whether there is a different way to meet it. > or will allow you to import a set of properties (or > property setting tasks) for example. I probably would not have needed if I had access to ... I feel it's a little hackish too, even though it serves my purpose just fine for now. The fact that ProjectComponent reference instances change Project when returned could have negative side effects for example??? > > Three +1s are required for a code change, so, by the likes of it, > > the vote will have a negative result. > > No, just no positive result. Sorry for dropping the ball on you ;-) I posted this code kinda showing off I guess, during the discussion if you recall, and also because it might be useful to somebody else. I looked at the Antelope one, and really didn't like the code duplication I saw there. So I hacked my own thanks to a loop hope related to the Introspection rules of Ant to get a hold of the nested private project... Would be cleaner in proper, but still not great. is the way to go forward I think. I'm just missing it with my 1.5.3 Ant used in production builds (augmented Ant, but not modified in any way). Thanks for proposing my code though. Cheers, --DD PS: Maybe Ant-Contrib would like to incorporate to compete on features with Antelope??? ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Ant/Antcall Returning properties and references [WAS] Re: ant 1.5.4 : Import
On Thu, 28 Aug 2003, Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote: > So far, I have got two +1 (myself and Jan Materne) for this > proposal. Just a quick comment from myself. I don't really like the idea of turning into a method call, that's why I won't give you a positive vote - unless I can get convinced which is pretty unlikely, given my stubbornness. >From past discussions - and we've had this one a couple of times - I have the impression that I'm not alone with my feeling so I more or less waited for somebody else to speak his mind (as I'm too busy myself to engage in longer arguments right now). You indicate yourself that we might be better of with postponing this. I'd like to explore the needs that is driving this specific feature request - and see whether there is a different way to meet it. or will allow you to import a set of properties (or property setting tasks) for example. > The vote will be closed tomorrow at 12:28 pm CET (20 hours from > now). We've never been that strict with deadlines 8-) > Three +1s are required for a code change, so, by the likes of it, > the vote will have a negative result. No, just no positive result. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Ant/Antcall Returning properties and references [WAS] Re: ant 1.5.4 : Import
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 , , tasks of Antelope provide functionality in terms of returning properties. This 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. And there is also enough work fixing small or large bugs in existing functionality. Cheers, Antoine - Original Message - From: "Antoine Levy-Lambert" <[EMAIL PROTECTED]> To: "Ant Developers List" <[EMAIL PROTECTED]> Sent: Friday, August 22, 2003 12:28 PM Subject: [VOTE] Ant/Antcall Returning properties and references [WAS] Re: ant 1.5.4 : Import > I think that the code of Dominique would add a lot of value to ant. > Instead of committing the code as is, I would like simply to add the new > features to the task. > This means that it should be a no brainer to have these features then also > in > Can we vote about introducing it ? > I start with my +1 > Cheers, > Antoine > - Original Message - > From: "Dominique Devienne" <[EMAIL PROTECTED]> > To: "'Ant Developers List'" <[EMAIL PROTECTED]> > Sent: Thursday, July 24, 2003 5:36 PM > Subject: RE: ant 1.5.4 : Import > > > > Then have a look at what I did in the past two days to do something > similar > > ;-) I created an task that piggybacks on , and allows > > returning properties and/or references from the called build file back > into > > the caller's context (Project). > > > > That would take care of that use case ;-) --DD > > > > > -Original Message- > > > From: Conor MacNeill [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, July 24, 2003 10:39 AM > > > To: Ant Developers List > > > Subject: Re: ant 1.5.4 : Import > > > > > > On Fri, 25 Jul 2003 01:23 am, Dominique Devienne wrote: > > > > > > > > I (strongly again ;) believe that imported build files should be > > > designed > > > > to be imported, and never used without being imported. > > > > > > I disagree (strongly :-). I think augmenting/overriding an existing > build > > > file > > > is a valid use for import. I recently changed the checkstyle build I > have > > > been using (check.xml) to import Ant's build.xml to pick up property > defs > > > for > > > various locations. Have a look. > > > > > > Conor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > // vim:ts=2:sw=2 > > package com.lgc.buildmagic.test; > > > > import org.apache.tools.ant.ProjectComponent; > > import org.apache.tools.ant.types.Path; > > import org.apache.tools.ant.types.FileSet; > > > > import com.lgc.buildmagic.util.BuildFileTestCase; > > > > /** > > * Tests. > > * > > * @author mailto:[EMAIL PROTECTED]">Dominique Devienne > > * @version Jul 2003 - Copyright (c) 2003, Landmark Graphics Corp. > > */ > > public class AntReturnTest > > extends BuildFileTestCase { > > > > public void testReturnProperty() { > > executeTarget("test-returnProperty"); > > > > assertProperty("propA", "a"); > > assertProperty("propB", null); > > assertProperty("propC", "ccc"); > > assertProperty("propD", null); > > } > > > > private void assertProperty(String name, String expectedValue) { > > String value = getProject().getProperty(name); > > assertEquals(name + " property", value, expectedValue); > > } > > > > public void testReturnReference() { > > executeTarget("test-returnReference"); > > > > assertReference("pathRef", Path.class); > > assertReference("filesetRef", FileSet.class); > > assertReference("patternsetRef", null); > > } > > > > private void assertReference(String refid, Class expectedClass) { > > Object value = getProject().getReference(refid); > > if (expectedClass != null) { > > assertNotNull(refid + " reference", value); > > assertEquals(refid + " reference type", expectedClass, > > value.getClass()); > > assertSame(refid + " reference project", getProject(), > > ((ProjectComponent)value).getProject()); > > } > > else { > > assertEquals(refid + " reference found", false, value != null); > > } > > } > > > > } // END class AntReturnTest > > > > // vim:ts=2:sw=2 > > package com.lgc.buildmagic; > > > > import java.util.List; > > import java.util.Iterator; > > import java.util.ArrayList; > > import java.util.Collectio
RE: [VOTE] Ant/Antcall Returning properties and references [WAS] Re: ant 1.5.4 : Import
+1 Jan > -Original Message- > From: Antoine Levy-Lambert [mailto:[EMAIL PROTECTED] > Sent: Friday, August 22, 2003 12:29 PM > To: Ant Developers List > Subject: [VOTE] Ant/Antcall Returning properties and references [WAS] > Re: ant 1.5.4 : Import > > > I think that the code of Dominique would add a lot of value to ant. > Instead of committing the code as is, I would like simply to > add the new > features to the task. > This means that it should be a no brainer to have these > features then also > in > Can we vote about introducing it ? > I start with my +1 > Cheers, > Antoine > - Original Message - > From: "Dominique Devienne" <[EMAIL PROTECTED]> > To: "'Ant Developers List'" <[EMAIL PROTECTED]> > Sent: Thursday, July 24, 2003 5:36 PM > Subject: RE: ant 1.5.4 : Import > > > > Then have a look at what I did in the past two days to do something > similar > > ;-) I created an task that piggybacks on , > and allows > > returning properties and/or references from the called > build file back > into > > the caller's context (Project). > > > > That would take care of that use case ;-) --DD > > > > > -Original Message- > > > From: Conor MacNeill [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, July 24, 2003 10:39 AM > > > To: Ant Developers List > > > Subject: Re: ant 1.5.4 : Import > > > > > > On Fri, 25 Jul 2003 01:23 am, Dominique Devienne wrote: > > > > > > > > I (strongly again ;) believe that imported build files should be > > > designed > > > > to be imported, and never used without being imported. > > > > > > I disagree (strongly :-). I think augmenting/overriding > an existing > build > > > file > > > is a valid use for import. I recently changed the > checkstyle build I > have > > > been using (check.xml) to import Ant's build.xml to pick > up property > defs > > > for > > > various locations. Have a look. > > > > > > Conor > > > > > > > > > > > > > > > > > > > > > > > > target="set-properties"> > > > > > > > > > > > > > > > > > > target="set-references"> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > // vim:ts=2:sw=2 > > package com.lgc.buildmagic.test; > > > > import org.apache.tools.ant.ProjectComponent; > > import org.apache.tools.ant.types.Path; > > import org.apache.tools.ant.types.FileSet; > > > > import com.lgc.buildmagic.util.BuildFileTestCase; > > > > /** > > * Tests. > > * > > * @author mailto:[EMAIL PROTECTED]">Dominique Devienne > > * @version Jul 2003 - Copyright (c) 2003, Landmark Graphics Corp. > > */ > > public class AntReturnTest > > extends BuildFileTestCase { > > > > public void testReturnProperty() { > > executeTarget("test-returnProperty"); > > > > assertProperty("propA", "a"); > > assertProperty("propB", null); > > assertProperty("propC", "ccc"); > > assertProperty("propD", null); > > } > > > > private void assertProperty(String name, String expectedValue) { > > String value = getProject().getProperty(name); > > assertEquals(name + " property", value, expectedValue); > > } > > > > public void testReturnReference() { > > executeTarget("test-returnReference"); > > > > assertReference("pathRef", Path.class); > > assertReference("filesetRef", FileSet.class); > > assertReference("patternsetRef", null); > > } > > > > private void assertReference(String refid, Class expectedClass) { > > Object value = getProject().getReference(refid); > > if (expectedClass != null) { > > assertNotNull(refid + " reference", value); > > assertEquals(refid + " reference type", expectedClass, > > value.getClass()); > > assertSame(refid + " reference project", getProject(), > > ((ProjectComponent)value).getProject()); > > } > > else { > > assertEquals(refid + " reference found", false, value > != null); > > } > > } > > > > } // END class AntReturnTest > > > > // vim:ts=2:sw=2 > > package com.lgc.buildmagic; > > > > import java.util.List; > > import java.util.Iterator; > > import java.util.ArrayList; > > import java.util.Collections; > > > > import org.apache.tools.ant.Project; > > import org.apache.tools.ant.ProjectComponent; > > import org.apache.tools.ant.BuildException; > > > > import org.apache.tools.ant.types.Reference; > > > > import org.apache.tools.ant.taskdefs.Ant; > > import org.apache.tools.ant.taskdefs.Property; > > > > /** > > * ... > > * > > * @author mailto:[EMAIL PROTECTED]">Dominique Devienne > > * @version Jul 2003 - Copyright (c) 2003, Landmark Graphics Corp. > > * > > * @ant.task category="control" > > */ > > public class AntReturn > > extends Ant { > > > > private Project _newProject; > > private ReturnedElements _r
