You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Mariusz Nowostawski <ma...@marni.otago.ac.nz> on 2000/05/26 00:43:12 UTC

[PATCH] exec with include/exclude

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

Posted by David Forslund <dw...@lanl.gov>.
The output of ant is:

E:\TMexport\TM2000\interfaces\omg>ant idl
Buildfile: build.xml
Project base dir set to: E:\TMexport\TM2000
Executing Target: prepare
Executing Target: check_for_optional_packages
Executing Target: idl
[exec] jidl -Iidl --tie --package org.omg --output-dir 
E:\TMexport\TM2000/interfaces/omg/src --file-list filelist in 
E:\TMexport\TM2000 for 21 files.
Completed in 83 seconds

I'm running jidl 4.0.

Dave

At 11:50 AM 5/27/00 +1200, Mariusz Nowostawski wrote:
>I have not checked that on windows, I run simple tests locally here on
>Linux only, but I suspect it should work on both the same.
>If your target looks something like this:
>
><target name="idls">
>     <exec dir="."
>           command="jidl --output-dir classes --package com.my.idl"
>           src="idls" output="out.txt"/>
></target>
>
>and inside ./idls you have your *.idl sources:
>0. Invoke: ant idls
>1. Check what you have after execution of the idls target inside out.txt;
>    in normal conditions this file should be empty, but if your jidl has
>    any troubles you can get the idea whats wrong from out.txt
>2. Make sure the output dir is already created (jidl I am using will
>    simply fail if you do not have output directory already created)
>3. If you still cannot guess whats wrong, show me your out.txt file, your
>    target and what ant is printing out when you executing idls target
>
>--
>As I said, I am using Linux, and I have not noticed any troubles here,
>with target like the one above, with jidl being ORBacus 3.1.3, I have:
>   my out.txt is empty,
>   ant is printing:
>
>$ ant idls
>
>Buildfile: build.xml
>Project base dir set to: /home/mariusz/Projects/nzdis/oql
>Executing Target: idls
>[exec] jidl --output-dir classes --package com.my.idl in 
>/home/mariusz/Projects/nzdis/oql for 3 files.
>Completed in 1 seconds
>
>   and inside classes/com/my/idl/* I have the expected java sources written
>correctly to disk.  I have not checked that on windows though..
>
>
>hope it helps
>Mariusz
>
>
> > I tried the patch and find the jidl program opens up a bunch of command
> > windows on NT and although jidl appears to process the idl files,
> > nothing is written to disk.
> >
> > Dave


Re: [PATCH] exec with include/exclude

Posted by David Forslund <dw...@lanl.gov>.
Actually, I was too quick to respond.   The command seems to run but fails 
to produce the resulting .java
files.  The same command outside of ant works fine.

Dave
At 06:08 PM 5/26/00 -0600, you wrote:

>At 11:50 AM 5/27/00 +1200, Mariusz Nowostawski wrote:
>>I have not checked that on windows, I run simple tests locally here on
>>Linux only, but I suspect it should work on both the same.
>>If your target looks something like this:
>>
>><target name="idls">
>>     <exec dir="."
>>           command="jidl --output-dir classes --package com.my.idl"
>>           src="idls" output="out.txt"/>
>></target>
>>
>>and inside ./idls you have your *.idl sources:
>>0. Invoke: ant idls
>>1. Check what you have after execution of the idls target inside out.txt;
>>    in normal conditions this file should be empty, but if your jidl has
>>    any troubles you can get the idea whats wrong from out.txt
>>2. Make sure the output dir is already created (jidl I am using will
>>    simply fail if you do not have output directory already created)
>>3. If you still cannot guess whats wrong, show me your out.txt file, your
>>    target and what ant is printing out when you executing idls target
>
>The out.txt file is empty (it was not empty when the command was failing).
>The command works just fine, it seems to open a new command window
>for every .idl file it is compiling  (it doesn't do this when running the 
>same command outside
>of ant).  The output directory is full.  The command seems to work 
>correctly and creates
>all the necessary files.    I can't send you want jidl is printing out, 
>because all the
>windows go away when the command completes.
>
>It alls seems to work, it just pops the annoying windows while it is running.
>
>Thanks,
>
>Dave
>
>
>>--
>>As I said, I am using Linux, and I have not noticed any troubles here,
>>with target like the one above, with jidl being ORBacus 3.1.3, I have:
>>   my out.txt is empty,
>>   ant is printing:
>>
>>$ ant idls
>>
>>Buildfile: build.xml
>>Project base dir set to: /home/mariusz/Projects/nzdis/oql
>>Executing Target: idls
>>[exec] jidl --output-dir classes --package com.my.idl in 
>>/home/mariusz/Projects/nzdis/oql for 3 files.
>>Completed in 1 seconds
>>
>>   and inside classes/com/my/idl/* I have the expected java sources written
>>correctly to disk.  I have not checked that on windows though..
>>
>>
>>hope it helps
>>Mariusz
>>
>>
>> > I tried the patch and find the jidl program opens up a bunch of command
>> > windows on NT and although jidl appears to process the idl files,
>> > nothing is written to disk.
>> >
>> > Dave


Re: [PATCH] exec with include/exclude

Posted by David Forslund <dw...@lanl.gov>.
At 11:50 AM 5/27/00 +1200, Mariusz Nowostawski wrote:
>I have not checked that on windows, I run simple tests locally here on
>Linux only, but I suspect it should work on both the same.
>If your target looks something like this:
>
><target name="idls">
>     <exec dir="."
>           command="jidl --output-dir classes --package com.my.idl"
>           src="idls" output="out.txt"/>
></target>
>
>and inside ./idls you have your *.idl sources:
>0. Invoke: ant idls
>1. Check what you have after execution of the idls target inside out.txt;
>    in normal conditions this file should be empty, but if your jidl has
>    any troubles you can get the idea whats wrong from out.txt
>2. Make sure the output dir is already created (jidl I am using will
>    simply fail if you do not have output directory already created)
>3. If you still cannot guess whats wrong, show me your out.txt file, your
>    target and what ant is printing out when you executing idls target

The out.txt file is empty (it was not empty when the command was failing).
The command works just fine, it seems to open a new command window
for every .idl file it is compiling  (it doesn't do this when running the 
same command outside
of ant).  The output directory is full.  The command seems to work 
correctly and creates
all the necessary files.    I can't send you want jidl is printing out, 
because all the
windows go away when the command completes.

It alls seems to work, it just pops the annoying windows while it is running.

Thanks,

Dave


>--
>As I said, I am using Linux, and I have not noticed any troubles here,
>with target like the one above, with jidl being ORBacus 3.1.3, I have:
>   my out.txt is empty,
>   ant is printing:
>
>$ ant idls
>
>Buildfile: build.xml
>Project base dir set to: /home/mariusz/Projects/nzdis/oql
>Executing Target: idls
>[exec] jidl --output-dir classes --package com.my.idl in 
>/home/mariusz/Projects/nzdis/oql for 3 files.
>Completed in 1 seconds
>
>   and inside classes/com/my/idl/* I have the expected java sources written
>correctly to disk.  I have not checked that on windows though..
>
>
>hope it helps
>Mariusz
>
>
> > I tried the patch and find the jidl program opens up a bunch of command
> > windows on NT and although jidl appears to process the idl files,
> > nothing is written to disk.
> >
> > Dave


Re: [PATCH] exec with include/exclude

Posted by Mariusz Nowostawski <ma...@marni.otago.ac.nz>.
I have not checked that on windows, I run simple tests locally here on
Linux only, but I suspect it should work on both the same. 
If your target looks something like this:

<target name="idls">
    <exec dir="."
          command="jidl --output-dir classes --package com.my.idl"
          src="idls" output="out.txt"/>
</target>

and inside ./idls you have your *.idl sources:
0. Invoke: ant idls
1. Check what you have after execution of the idls target inside out.txt;
   in normal conditions this file should be empty, but if your jidl has
   any troubles you can get the idea whats wrong from out.txt
2. Make sure the output dir is already created (jidl I am using will
   simply fail if you do not have output directory already created)
3. If you still cannot guess whats wrong, show me your out.txt file, your
   target and what ant is printing out when you executing idls target

--
As I said, I am using Linux, and I have not noticed any troubles here,
with target like the one above, with jidl being ORBacus 3.1.3, I have:
  my out.txt is empty, 
  ant is printing:

$ ant idls

Buildfile: build.xml
Project base dir set to: /home/mariusz/Projects/nzdis/oql
Executing Target: idls
[exec] jidl --output-dir classes --package com.my.idl in /home/mariusz/Projects/nzdis/oql for 3 files.
Completed in 1 seconds

  and inside classes/com/my/idl/* I have the expected java sources written
correctly to disk.  I have not checked that on windows though.. 


hope it helps
Mariusz


> I tried the patch and find the jidl program opens up a bunch of command
> windows on NT and although jidl appears to process the idl files,
> nothing is written to disk.
> 
> Dave



Re: [PATCH] exec with include/exclude

Posted by David Forslund <dw...@lanl.gov>.
I tried the patch and find the jidl program opens up a bunch of command 
windows on NT
and although jidl appears to process the idl files, nothing is written to disk.

Dave
At 10:43 AM 5/26/00 +1200, you 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

Posted by 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

Posted by 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

Posted by 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

Posted by 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

Posted by 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

Re: [PATCH] exec with include/exclude

Posted by 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