Peter, I have to appologize because I completely misunderstood what you where asking for. Maybe the fact that I had just started my day and had not have my cup of Tea. Anyway I thought what you were asking for was to get the "exit value" (aka exit code) of an execution. Which I really think it is a marginal issue.
Now I understand what you meant was getting the output of a command (i.e., stdout) on a property. OK, I agree that this is a completely different animal. Now, in this case I would really argue that maybe we need something better than just the specific case of the output of the <exec> task in particular. Looking at the code, there is already a way to redirect the output of <exec> to a file. <exec .... output="file/xyz" /> If I remember correctly, someone posted not long ago, a modification to <property> to allow loading the entire content of a file as the value for the property. I do not know if that was ever committed. Granted, it is not as absolutely simple as putting the value directly of the property, but it is quite close to it. <exec .... output="file/xyz" /> <property name="build" whateverTheAttributeWas="file/xyz" /> Now the advantage of this approach is that one can use the new way to load properties for other things. It is not a solution just for <exec> but it gives a more general power that can be used with other tasks in the future. But granted, this approach will leave little files as debrise all over, so it is not as good. I which there was a way to define intermetiate "files" in ANT which exists only in memory. Something like buffers that can hold the output of tasks or be used as the input for tasks. But that is a different can of worms all together. Jose Alberto > -----Original Message----- > From: Peter Vogel [mailto:[EMAIL PROTECTED] > Sent: Sunday, June 10, 2001 9:44 AM > To: '[EMAIL PROTECTED]' > Subject: RE: property value from the result of executing a process? > > > Hi Jose, > > you could also just extend the <exec> task. Quite simple for > > what I can see. > > Yeah, it is quite simple (I'm in the process now) but not for > *extension* rather for *modification of the existing*. > > > > > > From: Peter Vogel [mailto:[EMAIL PROTECTED] > > > > > > Ew! Let's see: > > > one process to generate the output + write a file > > > one process to massage the output + write a file > > > one task to read the massaged output + write to properties > > > > > > That's 2 processes, 3 tasks to accomplish what could be done > > > in 1 task, 1 process! > > > > > > > 2 Processes? 3 tasks? Wow! > > Well, I left unsaid what I was thinking: "there go all the claims > of performance over make (which are almost entirely due to the > pattern of using make recursively, rather than letting it in > on all the dependencies)". > > > > > > The problem with making it an optional task is then I've got to > > > go and build an xml syntax just to do the same thing the exec > > > task does with one minor difference! > > > > > > > Why dont you just extend your new task from <exec> it will look just > > something like: > > (Warning this it not compiled code, just a thought on how to > > do it simply). > > > > public class MyExec extends Exec > > { > > private String propName = null; > > public int run(String command) throws BuildException > > { > > if (propName != null) super.setFailOnError(false); > > int errCode = super.run(command); > > if (propName != null) { > > // call the method on project to set the property or whatever > > } > > } > > > > public void setProperty(String name) > > { > > propName = name; > > } > > } > > > > I think you get the idea. > > Yep! > > > > > BTW, on your buildfiles you could use <taskdef> and make > > <exec> use your new > > version. > > So that you do not even have to come up with a new XML name for it. > > Interesting thought. But then I've got taskdefs to explain to my > developer community -- not a pretty thought... > > > > > > Isn't this just the sort of "uncleanliness" that the ant committer > > > community is trying to avoid in their constant pursuit of a "pure" > > > core? We already have the ridiculous virtually identical "Apply" > > > and "ExecOn" for the minor difference of whether time stamps on > > > derived objects should be checked to determine if the tool needs > > > to be executed for each file or not, that could have been > handled by > > > an attribute. Now we're talking about an optional task, say > > > "execprop" > > > for the sake of argument that does the *exact* same thing > as "exec" > > > except for where the output goes... > > > > > > > I think that providing this little task, and seeing whether > > the rest of the > > community feels (after using it for a while) whether it is > > meaningful enough > > as to merge the functionality into the one in core, is a more relax > > approach. > > O.K. I admit it, this list gets my goat :-) I probably went a little > overboard... > > > > > > Let's face it, build identification is a common issue, > build numbers > > > are a common way to solve the issue. You could have a > > > bazillion revisions > > > of a "version" file checked in, one for each build, or you > > could take > > > advantage of the metadata capabilities of SCM systems out > > > there to store > > > the most recent build number and update it automatically. Which > > > makes more sense? > > > > > > > You lost me here, what does build numbers has to do with > > saving the exec value? > > Common pattern of usage -> grab the build number from the result of > executing an SCM tool command (my original example was to call > "cleartool describe -attr buildnum ${ant.file}" ant tuck its output > away... > > > > > > I've build build systems that worked with a wide variety of SCM > > > systems: CVS, ClearCase, Continuus, PerForce, etc. in all cases it > > > was possible to avoid the "version.h" or "version.java" > file having > > > more than a very few revisions for purposes other than updating > > > the build number by utilizing source metadata... I cannot be the > > > only one out there for whom this is useful, and this is > exactly the > > > sort of thing you'd *want* to encourage in the development > > > community, not > > > hide away in an optional task or optional task library on > the net... > > > > > > > Not to pick on this particular task, but if every feature > > that anyone may > > imagine to be useful to others needs to be put into core, > then we are > > actually going against the whole point of having an > > extensible tool. Why do > > I need extensibility and antlibs if we just put everything > > that is useful > > into CORE or into the ANT main src tree? > > O.K. Apply the same argument to Genkey, Tar, Sql, Unjar, Untar, Gzip, > Unwar, war, gunzip, etc. > > They're useful enough to a large enough set of people that they belong > in the core, at least I assume that's the argument. > > So, my point is that grabbing the output of a command is an extremely > common pattern in large project builds. Just reading over the past > few days worth of messages, I see several situations where having this > capability would simplify things for a lot of different > problems. Build > numbers are just the most obvious to me at the moment... > > > > > I think it is important to promote the writing of useful > > non-core tasks > > which are available for people to use. There is no reason to > > think of them > > as some sort of second rated. > > I'd agree, were it not for the "discretion" (I was going to say > "censorship" but decided to tone down my rhetoric) applied by > the committers evident in the fact that, for example, "<foreach>" > isn't in the optional distribution from the website. I'd call > that "second class" treatment, which is what I want to avoid here... > > > -Peter > > > > > -Peter > > > > > > > > > > > > > -----Original Message----- > > > > From: Craeg K Strong [mailto:[EMAIL PROTECTED] > > > > Sent: Saturday, June 09, 2001 10:55 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: property value from the result of executing > > a process? > > > > > > > > > > > > Peter Vogel wrote: > > > > > > > > >>Before I go and do this, I'm wondering if I'm just missing > > > > something. > > > > >> > > > > >>What I'm looking for is the ability to execute a process > > > > and store its > > > > >>output > > > > >>in a property, for example: > > > > >> > > > > >><property name="build" exec="cleartool describe -attr buildnum > > > > >>${ant.file}"/> > > > > >> > > > > >>Or, if you prefer: > > > > >> > > > > >><property name="build"> > > > > >> <exec executable="cleartool"> > > > > >> <arg line="describe -attr buildnum ${ant.file}"/> > > > > >> </exec> > > > > >></property> > > > > >> > > > > >>Or perhaps? > > > > >> > > > > >><target name="init"> > > > > >> <exec executable="cleartool" property="build"> > > > > >> <arg line="describe -attr buildnum ${ant.file}"/> > > > > >> </exec> > > > > >></property> > > > > >> > > > > >> > > > > >>This seems like a pretty obvious bit of functionality to > > > > have, so I'm > > > > >>surprised I > > > > >>didn't see it already. I'll implement if someone suggests > > > > the preferred > > > > >>syntax > > > > >>for this. > > > > >> > > > > >>-Peter > > > > >> > > > > > > > > > Sounds interesting. This is just the kind of task that > > > > could be in a > > > > "taskdefs.org" library of contributed optional tasks, IMO. > > > > Most of us would never need it, but for those few-- it > > > could be quite > > > > valuable. > > > > > > > > However, as a quick and dirty solution: > > > > Try executing the process, recording its output in a file, > > > converting > > > > that into java.util.Properties format, and then > > > > reading it in as a property file (e.g. <Property > > file="foo" /> ) > > > > > > > > HTH, > > > > > > > > --Craeg Strong > > > > > > > > -- > > > > Craeg K. Strong | > > www.arielpartners.com > > > Ariel Partners LLC | > > > [EMAIL PROTECTED] > > > 85 River Street, Ste. 3A | Fax: > > > (781) 647-9690 > > > Waltham, MA 02453 | Voice: > > > (781) 647-2425 > > > > > > > > > > > >
