Re: [PATCH] exec with include/exclude

[David Forslund <dw...@lanl.gov>]

I've used this patch and feature for my application.  Apparently,
it hasn't been "grafted" into the Ant distribution.  Has this
functionality of specifying a source directory for exec been added?
If so, how do I use it?

Thanks,

Dave
At 10:43 AM 5/26/00 +1200, Mariusz Nowostawski wrote:

>I wrote a trivial extension to the existing Exec task definition to make
>it include/exclude aware and I have already posted it here, but
>without any (positive or negative) feedback.
>
>With the patch, the Exec task will behave as usual if used as
>usual. However, if used with the additional optional attribute 'src' which
>should be a directory, it will search for files, and will exec a command
>with attached list of files as an additional last argument.
>'src' attribute can be renamed to 'dir' or whatever will be the 'standard
>look&feel' for matching tasks.
>
>One can use the modified Exec for any task which requires executing a
>binary program with a list of files being its arguments;
>for example to compile multiple *.idl files:
>
>(*) <exec dir="${basedir}"
>       command="jidl --output-dir ${src.dir} --package com.my.idl"
>       src="src/idls" output="out.txt"/>
>
>if inside ${basedir}/src/idls we have files: a.idl, b.idl, c.txt
>it would execute effectively:
>
>cd ${basedir}; jidl --output-dir src/main --package com.my.idl \
>${basedir}/src/idl/a.idl ${basedir}/src/idl/b.idl ${basedir}/src/idl/c.txt
>
>
>(*) <exec dir="${basedir}"
>       command="jidl --output-dir ${src.dir} --package com.my.idl"
>       src="src/idl" output="out.txt">
>       <include name="*.idl"/>
>     </exec>
>
>if inside ${basedir}/src/idls we have files: a.idl, b.idl, c.txt
>it would execute effectively:
>
>cd ${basedir}; jidl --output-dir src/main --package com.my.idl \
>${basedir}/src/idl/a.idl ${basedir}/src/idl/b.idl
>
>
>The patch assumes that the command should be invoked once with the list of
>all matching files appended to the list of arguments. I cannot find any
>use of executing commands in list of files sequentially file after file
>with unknown order but if somebody needs it, the patch can be easily
>extended (i.e. exec  task can be easily extended by additional
>flag: 'sequential="true"'). Maybe there are usefull file/source processors
>which can deal with single file at once only. All tools I use can take a
>list of arguments, and single invocation is enough.
>
>
>best regards
>Mariusz

Re: [PATCH] exec with include/exclude

[Stefan Bodewig <bo...@bost.de>]

>>>>> "MN" == Mariusz Nowostawski <ma...@marni.otago.ac.nz> writes:

 MN> But I want to do something, instead of idle waiting and
 MN> repeating: Stefan do something, Stefan do something ;o) This is
 MN> the only thing which bothers me a little.

Looks as if we had the release out of the door. 

I'm just waiting for the first reports that I've fooled up
everything. Soon after the Announcement of the release is out, I'm
going to start working on the new stuff - so your time of idle waiting
may be over soon 8^).

Stefan

Re: [PATCH] exec with include/exclude

[Mariusz Nowostawski <ma...@marni.otago.ac.nz>]

On 17 Jul 2000, Stefan Bodewig wrote:
> [...]
>                      - do you think a delay of a few days would be
> important enough to commit an intermediate solution (this is by no
> means a rhetoric question)?

No, I do not think it is that important, and few days is not a big deal
here.   For the time being people can use the old patched thing anyway.
Are you positively sure it was not rhetorical question?  ;o)

But I want to do something, instead of idle waiting and repeating: Stefan
do something, Stefan do something ;o)
This is the only thing which bothers me a little.
Although it was pretty easy and straightforward to patch the existing
codebase to get this additional functionality, it is extremely difficult
to sit doing nothing and wait, wasting some of the evenings for the
codebase to become "workable" again and to get the possibility to work on
extending the functionality.  We have here small 'deadlock' problem.
Of course, I am pretty busy with other things and this 'waiting' is not
that bad anyway ;o)

cheers
Mariusz

Re: [PATCH] exec with include/exclude

[Stefan Bodewig <bo...@bost.de>]

Mariusz, you are right that this functionality should be available to
users ASAP, just a few notes.

The most pressing need for a new release is that there are so many
bugfixes/enhancements against the last official version (from _March_)
that we want the users to be aware of. "Modern compile" springs to
mind as well as many other things.

I really want to have this kind of release _now_.

If we are going to wait for the things from our TODO lists to be
implemented - well even if I could spend as much time on Ant as I
devote right now much longer (which I probably can't), I could go
coding for weeks before I'd even see the end of this list.

As for the Exec with matching task behavior thingie. I've switched my
priorities a little - as I seem to be less overwhelmed with real life
work than Thomas, I'm going to focus on changing the Exec inerts
first.

Of course we could provide a first shot on the modified Exec task
(using the current Exec and applying your patch) very fast. I'm
certain I could build a version that sits on top of the new framework
by the end of this week - do you think a delay of a few days would be
important enough to commit an intermediate solution (this is by no
means a rhetoric question)?

Stefan

Re: [PATCH] exec with include/exclude

[Mariusz Nowostawski <ma...@marni.otago.ac.nz>]

There are two sides of the story here, one side is the internal
organization of ANT itself, design patterns, reuse of code etc, etc. 
I totally agree that reworking of execution model is necessary, and the
Thomas/Stefan new proposed model will be far better than the current one. 

However, the second side of the story is, that the ANT user _does not
care_ at all how ANT is organized internally. What the user cares about,
is functionality which ANT offers or not.  I suggest, we could think of
the "interface", i.e. the task name + task attribute names, and add it for
the time being with crapy implementation (with code duplication, no
reuse, etc)  and than "rework" it later.  
I even think this "interface-goes-first" model of development might prove
to be better, than "what-goes-inside-must-be-perfect-first"... 

If we provide new task with standard "interface", we might rework the
internal details later, and it will not influence the user at all. From
the very begining everybody is using Javac, but Javac is not finished
still, and it is not likely to be finished soon either... if we
said: 'Javac will be added later once we sort out all the internal
details', nobody would use ANT at all.

I also think, the "release" is all about functionality, new/changed task
names, attribute names, etc, not about how-we-did-it-this-time inside. 

just the thought
Mariusz


>  DF> I've used this patch and feature for my application.  Apparently,
>  DF> it hasn't been "grafted" into the Ant distribution.  Has this
>  DF> functionality of specifying a source directory for exec been
>  DF> added?  If so, how do I use it?
> 
> It has not been added for some reasons, one of them being that a
> directory based Exec task would be somewhat ambiguos. We agreed on
> reworking this a little - crafting a new task that would combine Exec
> with MatchingTask but that would be new task of its own right.
> 
> I'm going to work on this, it's on my TODO list but only at position
> five or six - I really want to include Thomas Haas execution framework
> before I start anything like this, as this will improve Exec itself a
> lot.
> 
> Oh and yes, this won't happen before the scheduled Ant release either
> I'm afraid.

Re: [PATCH] exec with include/exclude

[Stefan Bodewig <bo...@bost.de>]

>>>>> "DF" == David Forslund <dw...@lanl.gov> writes:

 DF> I've used this patch and feature for my application.  Apparently,
 DF> it hasn't been "grafted" into the Ant distribution.  Has this
 DF> functionality of specifying a source directory for exec been
 DF> added?  If so, how do I use it?

It has not been added for some reasons, one of them being that a
directory based Exec task would be somewhat ambiguos. We agreed on
reworking this a little - crafting a new task that would combine Exec
with MatchingTask but that would be new task of its own right.

I'm going to work on this, it's on my TODO list but only at position
five or six - I really want to include Thomas Haas execution framework
before I start anything like this, as this will improve Exec itself a
lot.

Oh and yes, this won't happen before the scheduled Ant release either
I'm afraid.

Stefan