axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mseib...@us.ibm.com
Subject Re: [axis] VOTE: drop redesigned test and samples process
Date Mon, 22 Jul 2002 18:12:46 GMT
Steve,

This is great feedback.  I will start on most of these suggestions as pre-
PHASE2 work, so that when we get to that point in the next week or so,
these suggestions can be realized.

Thanks again!

Matt Seibert                                           mseibert@us.ibm.com
IBM        External:    (512) 838-3656      Internal:   678-3656


                                                                                         
                                   
                      "Steve Loughran"                                                   
                                   
                      <steve_l@iseran.         To:       "axis-dev" <axis-dev@xml.apache.org>
                               
                      com>                     cc:                                    
                                      
                                               Subject:  Re: [axis] VOTE: drop redesigned
test and samples process           
                      07/22/2002 12:26                                                   
                                   
                      Please respond to                                                  
                                   
                      axis-dev                                                           
                                   
                                                                                         
                                   




----- Original Message -----
From: <butek@us.ibm.com>
To: <axis-dev@xml.apache.org>
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.
> apache.org/~butek/test.tar.  Once you grab and untar that file, take a
look
> at AxisTestRedesign.html.  We'll commit his phase 1 stuff today.
>
> Russell Butek
> butek@us.ibm.com


I like ot; it is much cleaner and much lower maintenance. I think it should
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

test/something/build/webapps/axis

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
stops
you running the builds standalone.

Proposed change:

**we get used to running build files in the directory they live, and modify
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"/>
  </target>

would become

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

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}/build.properties"/>

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
tree.

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,
all
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




Mime
View raw message