ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Vogel <pvo...@arsin.com>
Subject RE: property value from the result of executing a process?
Date Sun, 10 Jun 2001 08:43:58 GMT
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:pvogel@arsin.com]
> >
> > 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:cstrong@arielpartners.com]
> > > Sent: Saturday, June 09, 2001 10:55 PM
> > > To: ant-dev@jakarta.apache.org
> > > 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		              |
> > cstrong@arielpartners.com
> > 85 River Street, Ste. 3A                      | Fax:
> > (781) 647-9690
> > Waltham, MA 02453                             | Voice:
> > (781) 647-2425
> >
> >
> >
> 

Mime
View raw message