I guess I didn't make a few points too clear...

1) The process does not require editing the build<Test/Samples>.xml files UNLESS there is a inter-target dependancy. I added names for all of the known tests when I started a month of so ago, but these aren't necessary. A new test just requires a buildComponent.xml file be created, and the system scans for these when it compiles (and eventually runs). So there isn't a required top-level list that needs updating.

1.5 ) You do still have to call everything from the top level, but that is going to be alleviated in the near future (I hope)....

2) I can continute on the side, but I would ask that anyone who is working on a test to update the buildComponent.xml files as they go, so I don't have to try to keep things in sync in this ever changing landscape. I have just spent a day and a half catching up on that changes of the last two weeks. My main rationale of moving this into the main process was to eliminate my need to have to keep up the syncs, as it would be in the mainline... But, I'll also be the first to admit that I really don't like this being incomplete. If everyone can help me keeping up this side-line stuff, then I'm more than happy to be able to work more on this on the side. That would make me a lot happier :)

Matt Seibert mseibert@us.ibm.com
IBM External: (512) 838-3656 Internal: 678-3656
Glen Daniels <gdaniels@macromedia.com>
Hi guys!
 
Here's what I really don't like about this approach: if you add a new test, you need to add a test "name" for that at the top level, and you have to call everything from the top.
 
I would VASTLY prefer (even to the point of waiting on this stuff) having the individual test build.xml files just work from their own directories.  That way we don't need to keep a "master list" anywhere which needs updating, you could just have the top level look for "build.xml"s (or buildComponent.xml at present) in any directory under test/ and run them.
 
I could see getting this stuff as it stands in IF we had componentized execution working already as well, but a) we don't, and b) it seems like getting the individual component build.xml's to work is going to be a pretty serious change - why not just do that while this stuff is off to the side, instead of impacting the mainline build process twice (once now once when the next phase happens).
 
My apologies if I'm not completely understanding the process - I admit I haven't recently gone back and read your note about the structure.  I'll go look at that, and also Steve's rationale for using DTDs and entities, because frankly that seems pretty odious to me as well - isn't there a nicer-looking way? :)
 
--Glen
-----Original Message-----
From: mseibert@us.ibm.com [mailto:mseibert@us.ibm.com]
Sent: Friday, August 02, 2002 11:07 AM
To: axis-dev@xml.apache.org
Subject: Re: PLEASE REVIEW: Fw: cvs commit: xml-axis/java buildTest.xml


You can ignore them... they are meaningless. I am working on the "override" outputs today, to try and figure that out, but the DEPRECATEDs are going to take some digging, as I don't know where they came from.....

If you want to BUILD a component by itself, and if it has a target in build<Test/Samples>.xml that can be done, but the componentized execution isn't available yet.

Matt Seibert mseibert@us.ibm.com
IBM External: (512) 838-3656 Internal: 678-3656
[IMAGE]Russell Butek/Austin/IBM@IBMUS

Matt, good work! Some questions:

I get a couple sets of this output:

setenv:
[available] DEPRECATED - <available> used to override an existing property.
[available] Build file should not reuse the same property name for different values.
[available] DEPRECATED - <available> used to override an existing property.
[available] Build file should not reuse the same property name for different values.
[available] DEPRECATED - <available> used to override an existing property.
[available] Build file should not reuse the same property name for different values.

and quite a number of:

Trying to override old definition of task foreach
Trying to override old definition of task runaxisfunctionaltests
Trying to override old definition of task wsdl2java
Trying to override old definition of task java2wsdl

They don't seem to affect the build. Can I really ignore them, or is something wrong in my environment? If I really CAN ignore them, is there a way to get rid of them?

Also, there are a number of test/wsdl tests that aren't run. It starts with interop3, skipping all those alphabetically before it. I don't want to replace our existing stuff until all of the tests can be run.

Last question. I think you showed us once how to do this, but I can't remember. If I wanted to run, say, test/wsdl/roundtrip all alone, how would I do that?

Russell Butek
butek@us.ibm.com


Please respond to axis-dev@xml.apache.org

To: axis-dev@xml.apache.org
cc:
Subject: PLEASE REVIEW: Fw: cvs commit: xml-axis/java buildTest.xml



Guys,

I just finished up closing the regressions of my buildTest and buildSamples structures with what is currently running. It is all in CVS. I would like to move from the "old" method to my structure tomorrow, if there are no objections.

To see it in action, please do the following:

ant clean compile
ant -buildfile buildPreTestTaskdefs.xml


If you should run into any problems, please let me know......

Matt Seibert mseibert@us.ibm.com
IBM External: (512) 838-3656 Internal: 678-3656
----- Forwarded by Matt Seibert/Austin/IBM on 08/01/2002 13:22 -----


[IMAGE]
    [IMAGE]

    seibert@apache.org

    08/01/2002 13:23
    Please respond to axis-dev
      [IMAGE]

      To: xml-axis-cvs@apache.org
      cc:
      Subject: cvs commit: xml-axis/java buildTest.xml

seibert     2002/08/01 11:23:21

 Modified:    java      buildTest.xml
 Log:
 Now we have 100% success on  the tests that are being run
 
 Revision  Changes     Path
 1.10      +17 -0      xml-axis/java/buildTest.xml
 
 Index:  buildTest.xml
 ===================================================================
 RCS  file: /home/cvs/xml-axis/java/buildTest.xml,v
 retrieving revision  1.9
 retrieving revision 1.10
 diff -u -r1.9  -r1.10
 --- buildTest.xml 1 Aug 2002 16:06:13 -0000 1.9
 +++  buildTest.xml 1 Aug 2002 18:23:21 -0000 1.10
 @@ -292,6 +292,23  @@
      </java>
     </target>
 
 +  <target  name="junit-functional-secure" if="junit.present"  depends="junit-functional-prepare,start-signature-signing-and-verification">
 +     <!-- now, run the actual test -->
 +     <junit dir="." printsummary="yes"  haltonfailure="${test.functional.fail}" fork="yes">
 +       <classpath refid="classpath" />
 +       <formatter type="xml"  usefile="${test.functional.usefile}"/>
 +       <batchtest todir="${test.functional.reportdir}">
 +         <fileset dir="${build.dest}">
 +           <!-- Convention: each package that's being  tested
 +                has  its own test class collecting all the tests -->
 +               <include name="**/TestBidBuySample.class"  />
 +              <exclude  name="**/Interop3TestCase.class"/>
 +         </fileset>
 +       </batchtest>
 +    </junit>
 +   </target>
 +
 +
    <!--  ===================================================================  -->
    <!-- Start Signature Signing and Verification  -->
    <!--  ===================================================================  -->
 
 
 
[IMAGE]




#### graycol.gif has been removed from this note on August 02 2002 by Matt Seibert
#### C7635590.gif has been removed from this note on August 02 2002 by Matt Seibert