Well, you could also just extend the <exec> task. Quite simple for what I can see.
> 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! > 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. 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. > 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. > 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? > 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? 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. Jose Alberto > -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 > > >
