Exec and MatchingTask

[Thomas Haas <th...@softwired-inc.com>]

Hi

I like the discussion started about MatchingTask and Exec. Implementing 
the JUnit, JavaCC and others I faced similar problems. The problem is 
that tasks should use functionality instead of inherit. Therefor I did 
an Execution FrameWork to be used by tasks. If you need executiona and 
matching, inherit from MatchingTask and use the execution facility from 
the execution framwork.

I attached some of the classes.
The framework currently provides:
- Easy handling of commandline parameters
- Customizable input and output stream handlers including compatibvility 
to the old log based output of Exec
- watchdog, killing processes running for too long
- easy evaluation of the return code of the subprocess
- command line definition using nested XML elements

The framework currently does not provide:
- setting of current directory like Exec does (which can be added easily 
by extending Commandline)


- tom

Re: Dependancy problem?

[Peter Donald <do...@mad.scientist.com>]

At 02:52  28/6/00 -0400, you wrote:
>I have a "test" target in my build.xml file which runs my test program 
>after ensuring that it is compiled. Unfortunately, every time I run it, it 
>also recompiles the test code, even after it was previously compiled. Here 
>is the relevant section of the build file:

Can you send the output of "build.sh -verbose" to list ?

Cheers,

Pete

*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power."          |
|       -Abraham Lincoln                               |
*------------------------------------------------------*

Dependancy problem?

[Russell Gold <ru...@acm.org>]

I posted this yesterday and received no responses. I cannot tell whether 
that is because nobody knows the answer, everyone things that the answer is 
too obvious to bother with, or the subject I chose was somehow filtered 
out, so I am trying again with a different subject...

I have a "test" target in my build.xml file which runs my test program 
after ensuring that it is compiled. Unfortunately, every time I run it, it 
also recompiles the test code, even after it was previously compiled. Here 
is the relevant section of the build file:
<!-- =================================================================== -->
<!-- Compiles the test code -->
<!-- =================================================================== -->
<target name="testcompile" depends="compile">
<javac srcdir="${src.dir}/test" destdir="${build.classes}" 
classpath="${classpath}"
debug="on" deprecation="off" optimize="on">
</javac>
</target>

<!-- =================================================================== -->
<!-- Runs the test code -->
<!-- Note: the classpath variable must be set on the command line -->
<!-- =================================================================== -->
<target name="test" depends="testcompile">
<java classname="com.meterware.httpunit.HttpUnitSuite"
fork="yes" classpath="${build.classes};${classpath}" >
</java>
</target>
Can anyone tell me what I am doing wrong? The full program can be found at 
<http://httpunit.sourceforge.net/>

Is this behavior intended?

Unneeded rebuild?

[Russell Gold <ru...@acm.org>]

I have a "test" target in my build.xml file which runs my test program 
after ensuring that it is compiled. Unfortunately, every time I run it, it 
also recompiles the test code, even after it was previously compiled. Here 
is the relevant section of the build file:

><!--  =================================================================== 
>-->
><!--  Compiles the test code                                               -->
><!--  =================================================================== 
>-->
><target name="testcompile" depends="compile">
>     <javac srcdir="${src.dir}/test" destdir="${build.classes}" 
> classpath="${classpath}"
>            debug="on" deprecation="off" optimize="on">
>     </javac>
></target>
>
>
><!--  =================================================================== 
>-->
><!--  Runs the test code                                                   -->
><!--  Note: the classpath variable must be set on the command line         -->
><!--  ===================================================================  -->
><target name="test" depends="testcompile">
>     <java classname="com.meterware.httpunit.HttpUnitSuite"
>           fork="yes" classpath="${build.classes};${classpath}" >
>     </java>
></target>

Can anyone tell me what I am doing wrong?  The full program can be found at 
<http://httpunit.sourceforge.net/>

Re: Exec and MatchingTask

[Thomas Haas <th...@softwired-inc.com>]

bodewig@bost.de (Stefan Bodewig) wrote:
> 
> >>>>> "TH" == Thomas Haas <th...@softwired-inc.com> writes:
> 
>  TH> The problem is that tasks should use functionality instead of
>  TH> inherit.
> 
> We do agree completely here. 
> 
> My proposal to get a reusable MatchingTask functionality was a first
> step, I retained MatchingTask with it's current contract to ease the
> shift from inheritance to delegation here.
> 
> I knew what you'd been working on with regard to Exec so I didn't talk
> about refactoring Exec at all.
> 
> I just don't think we should be making both transitions (changing the
> hows of Exec and MatchingTask) at the same time and refactoring the
> MatchingTask-like classes seemed to be the easier starting point.
> 
> Stefan
what else to say :-)
completly agree 100%.

I try the same with exec.



- tom

Re: Exec and MatchingTask

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

>>>>> "TH" == Thomas Haas <th...@softwired-inc.com> writes:

 TH> The problem is that tasks should use functionality instead of
 TH> inherit.

We do agree completely here. 

My proposal to get a reusable MatchingTask functionality was a first
step, I retained MatchingTask with it's current contract to ease the
shift from inheritance to delegation here.

I knew what you'd been working on with regard to Exec so I didn't talk
about refactoring Exec at all.

I just don't think we should be making both transitions (changing the
hows of Exec and MatchingTask) at the same time and refactoring the
MatchingTask-like classes seemed to be the easier starting point.

Stefan