= > 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.
Agreed, very marginal. Process exit code is a matter for Ant to deal with (i.e. failonerror) not often (ever?) needed in a real build (I suppose there's probably someone out there using the return code of "grep" in a makefile, but again, 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. Great! > > 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. Well, I cannot think of another task I'd need to snag the output of, but you may be right... > > 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. That'd be a pretty good workaround, though not as elegant (IMHO) as allowing exec to set a property or a property to encapsulate an exec. But that's why I brought up the discussion before I went and hacked at ant -- to get a feel for the communities preferences for this kind of functionality. So, was the set a property's value from a file implemented? > 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. Very true! > > But granted, this approach will leave little files as debrise > all over, so it is not as good. Right, unless you add in an <delete> task, so now we're talking 3 tasks to describe what could be described in one shot (exec this command and stick the output in this property). >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. Indeed. So, what's the feeling of the community? Should I submit a patch to the exec task that implements an "outputproperty" attribute? -Peter > > -----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 > > > > > > > > > > > > > > > > > >
