ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Vogel <>
Subject RE: property value from the result of executing a process?
Date Sun, 10 Jun 2001 06:59:33 GMT
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!

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!

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...

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?

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 "" 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...


> -----Original Message-----
> From: Craeg K Strong []
> Sent: Saturday, June 09, 2001 10:55 PM
> To:
> 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 
> "" 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                               |
> Ariel Partners LLC		              | 
> 85 River Street, Ste. 3A                      | Fax:      
> (781) 647-9690
> Waltham, MA 02453                             | Voice:    
> (781) 647-2425

View raw message