axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [axis] VOTE: drop redesigned test and samples process
Date Mon, 22 Jul 2002 17:57:52 GMT
+1 to dropping as-is.

I agree that we can do some cleanup on this, but that can be done as we go 
forward.  There is no need to wait for more effort on Matt's part if what 
he has now is already better than what we've got now.

Richard A. Sitze
IBM WebSphere WebServices Development

"Steve Loughran" <>
07/22/2002 12:26 PM
Please respond to axis-dev
        To:     "axis-dev" <>
        Subject:        Re: [axis] VOTE: drop redesigned test and samples process


----- Original Message -----
From: <>
To: <>
Sent: Monday, July 22, 2002 8:18 AM
Subject: Re: [axis] VOTE: drop redesigned test and samples process

> Folks, for those interested, I've dropped Matt's work onto http://xml.
>  Once you grab and untar that file, take a
> at AxisTestRedesign.html.  We'll commit his phase 1 stuff today.
> Russell Butek

I like ot; it is much cleaner and much lower maintenance. I think it 
go through one more iteration, for even better isolation and scaling. but
what is there right now is a lot better than before.

1. properties.xml
I'd use <property location> a lot more often over <property value>, as it
does make a difference on big build files. In particular a lot of stuff
seems to be defined relative to axis/java, but when included in some sub
build file, they will be coming in relative to tests/something. So where
there is something like

<property name="build.webapp" value="build/webapps/axis" />

it really will translate to


This only happens if you call <ant> with the build directory set to the
directory of the test
    <ant dir="test/something" />
rather than the directory of axis base
    <ant antfile="test/something" />

Historically in axis the build files have all done the latter, but IMO it
isnt the right approach for a very large build as it confuses all the code
in that build directory as to where things like the src dir is, and it 
you running the builds standalone.

Proposed change:

**we get used to running build files in the directory they live, and 
the properties files and build files accordingly. **

The changes will be in buildcompile and buildtest.xml

Things like
  <target name="RFCDispatch" depends="setenv">
    <ant inheritAll="true" antfile="test/RFCDispatch/buildComponent.xml"/>

would become

  <target name="RFCDispatch" depends="setenv">
    <ant inheritAll="true" antfile="buildComponent.xml"
dir="test/RFCDispatch" />

to carry the same trick off in the <foreach> task would need use of the
<dirname> and <basename> tasks that split a filename up.

Returning to the properties file I'd define all these things as locations
relative to a base directory

  <property name="masterbuild.dir" location=".."/>

pull in stuff from that directly
  <property file="${masterbuild.dir}/"/>

or from dirs beneath it

<property name="lib.dir" location="${masterbuild.dir}/lib"/>
<property name="build.dir" location="${masterbuild.dir}/build"/>
<property name="junit.jar" value="${lib.dir}/junit.jar" />
<property name="build.webapp" value="${build.dir}/webapps/axis" />

the use of explicit properties everywhere makes it much easier to build
something out the axis tree altogether, or in a different place in the 

This change will work regardless of how the sub projects are being called;
indeed, with masterbuild.dir defined to a location in the toplevel file, 
the references will fall out automatically.


Also in path_refs.xml; use of env.ANT_HOME
 -it is only optional to have ANT_HOME defined as an env variable; if it
aint set ant.{bat,sh,pl} sets it to the exe dir/.. , and passes it down as
the property ant.home
 -but IDEs (like intellij) dont set ant.home

so really properties.xml should have the line
 <property name="ant.home" value="env.ANT_HOME" /> to overwrite ant.home
only when it is not defined already

View raw message