Return-Path: Delivered-To: apmail-xml-axis-dev-archive@xml.apache.org Received: (qmail 16763 invoked by uid 500); 2 Aug 2002 15:45:40 -0000 Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@xml.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-dev@xml.apache.org Received: (qmail 16707 invoked from network); 2 Aug 2002 15:45:36 -0000 Subject: RE: PLEASE REVIEW: Fw: cvs commit: xml-axis/java buildTest.xml To: axis-dev@xml.apache.org X-Mailer: Lotus Notes Build V60_M13_04302002 Pre-release 2 April 30, 2002 Message-ID: From: mseibert@us.ibm.com Date: Fri, 2 Aug 2002 10:45:37 -0500 X-MIMETrack: Serialize by Router on D04NM206/04/M/IBM(Build M13TT_07122002 Pre-release 2|July 12, 2002) at 08/02/2002 11:45:38 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBE69ADFC6DC258f9e8a93df938690918c0ABBE69ADFC6DC25" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N --0__=0ABBE69ADFC6DC258f9e8a93df938690918c0ABBE69ADFC6DC25 Content-type: multipart/alternative; Boundary="1__=0ABBE69ADFC6DC258f9e8a93df938690918c0ABBE69ADFC6DC25" --1__=0ABBE69ADFC6DC258f9e8a93df938690918c0ABBE69ADFC6DC25 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable I guess I didn't make a few points too clear... 1) The process does not require editing the build.xml fil= es UNLESS there is a inter-target dependancy. I added names for all of th= e known tests when I started a month of so ago, but these aren't necessar= y. A new test just requires a buildComponent.xml file be created, and the system scans for these when it compiles (and eventually runs). So ther= e 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 work= ing 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 l= ike this being incomplete. If everyone can help me keeping up this side-li= ne 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 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=A0yo= u have to=A0call everything from the top. I would VASTLY prefer (even to the point of waiting on this stuff) havi= ng the individual test build.xml files just work from their own directorie= s. 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 th= em. 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 lik= e 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 t= o 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.=A0 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.xm= l You can ignore them... they are meaningless. I am working on the "override" outputs today, to try and figure that out, but the DEPRECAT= EDs 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.xml that can be done, but the componentized execut= ion 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 - used to override an existing property. [available] Build file should not reuse the same property name for different values. [available] DEPRECATED - used to override an existing property. [available] Build file should not reuse the same property name for different values. [available] DEPRECATED - 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 the= re 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 wa= nt 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 C= VS. I would like to move from the "old" method to my structure tomorrow, i= f 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 ----- = [IMA = GE] [IMAGE] [IMAGE] = = seibert@apache.org To: xml-axis-cvs@apache.org = cc: = 08/01/2002 13:23 Subject: cvs commit: xml-axis/java = Please respond to buildTest.xml = axis-dev = = = = seibert =A0 =A0 2002/08/01 11:23:21 =A0Modified: =A0 =A0java =A0 =A0 buildTest.xml =A0Log: =A0Now we have 100% success on the tests that are being run =A0Revision =A0Changes =A0 =A0Path =A01.10 =A0 =A0 =A0+17 -0 =A0 =A0 xml-axis/java/buildTest.xml =A0Index: buildTest.xml =A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =A0RCS file: /home/cvs/xml-axis/java/buildTest.xml,v =A0retrieving revision 1.9 =A0retrieving revision 1.10 =A0diff -u -r1.9 -r1.10 =A0--- buildTest.xml 1 Aug 2002 16:06:13 -0000 1.9 =A0+++ buildTest.xml 1 Aug 2002 18:23:21 -0000 1.10 =A0@@ -292,6 +292,23 @@ =A0 =A0 =A0 =A0 =A0 =A0+ =A0 =A0+ =A0 =A0 =A0+ =A0 =A0 =A0+ =A0 =A0 =A0 =A0+ =A0 =A0 =A0 =A0+ =A0 =A0 =A0 =A0+ =A0 =A0 =A0 =A0 =A0+ =A0 =A0 =A0 =A0 =A0 =A0+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+ =A0 =A0 =A0 =A0 =A0+ =A0 =A0 =A0 =A0+ =A0 =A0 =A0+ =A0 =A0+ =A0+ =A0 =A0 =A0 =A0 =A0 =A0 [IMAGE] #### graycol.gif has been removed from this note on August 02 2002 by M= att Seibert #### C7635590.gif has been removed from this note on August 02 2002 by = Matt Seibert= --1__=0ABBE69ADFC6DC258f9e8a93df938690918c0ABBE69ADFC6DC25 Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable I guess I didn't make a few points too clear...

1) The process does not require editing the build<Test/Samples>.x= ml 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 cr= eated, 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 work= ing on a test to update the buildComponent.xml files as they go, so I d= on'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 th= e last two weeks. My main rationale of moving this into the main proce= ss was to eliminate my need to have to keep up the syncs, as it would b= e in the mainline... But, I'll also be the first to admit that I reall= y 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
3D""Glen Daniels <gdaniels@macromedia.com>= ;
Hi guys!
=A0
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=A0you have to=A0call everything from the top.
=A0
I would VASTLY prefer (even to the point of waiting on this stuff) havi= ng the individual test build.xml files just work from their own direct= ories.=A0 That way we don't need to keep a "master list" any= where which needs updating, you could just have the top level look for= "build.xml"s (or buildComponent.xml at present) in any dire= ctory under test/ and run them.
=A0
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 li= ke 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 of= f to the side, instead of impacting the mainline build process twice (= once now once when the next phase happens).
=A0
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.=A0= I'll go look at that, and also Steve's rationale for using DTDs and e= ntities, because frankly that seems pretty odious to me as well - isn'= t there a nicer-looking way? :)
=A0
--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 build= Test.xml


You can ignore them... they are meaningless. I am wor= king on the "override" outputs today, to try and figure that= out, but the DEPRECATEDs are going to take some digging, as I don't k= now 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 t= he componentized execution isn't available yet.

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

Matt, good work! Some questions:

I get a couple sets of this output:

setenv:
[available] DEPRECATED - <available> used to ov= erride an existing property.
[available] Build file should not reuse the same prop= erty name for different values.
[available] DEPRECATED - <available> used to ov= erride an existing property.
[available] Build file should not reuse the same prop= erty name for different values.
[available] DEPRECATED - <available> used to ove= rride an existing property.
[available] Build file should not reuse the same prop= erty name for different values.

and quite a number of:

Trying to override old definition of task foreach
Trying to override old definition of task runaxisfunc= tionaltests
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 igno= re them, or is something wrong in my environment? If I really CAN igno= re 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 bef= ore it. I don't want to replace our existing stuff until all of the te= sts can be run.

Last question. I think you showed us once how to do t= his, 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 buil= dTest and buildSamples structures with what is currently running. It i= s 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:<= br>
ant clean compile
ant -buildfile buildPreTestTaskdefs.xml


If you should run into any problems, please let me kn= ow......

Matt Seibert mseibert@us.ibm.com
IBM External: (512) 838-3656 Internal: 678-3656
----- Forwarded by Matt Seibert/Austin/IBM on 08/01/2= 002 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 =A0 =A0 2002/08/01 11:23:21
=A0Modified: =A0 =A0java  =A0 =A0 buildTest.x= ml
=A0Log:
=A0Now we have 100% success on  the tests tha= t are being run
=A0
=A0Revision =A0Changes =A0  =A0Path
=A01.10 =A0 =A0 =A0+17 -0 =A0 =A0  xml-axis/j= ava/buildTest.xml
=A0
=A0Index:  buildTest.xml
=A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
=A0RCS  file: /home/cvs/xml-axis/java/buildTe= st.xml,v
=A0retrieving revision  1.9
=A0retrieving revision 1.10
=A0diff -u -r1.9  -r1.10
=A0--- buildTest.xml 1 Aug 2002 16:06:13 -0000 1.9=
=A0+++  buildTest.xml 1 Aug 2002 18:23:21 -00= 00 1.10
=A0@@ -292,6 +292,23  @@
=A0 =A0 =A0 </java>
=A0 =A0  </target>
=A0
=A0+ =A0<target  name=3D"junit-functi= onal-secure" if=3D"junit.present"  depends=3D"= junit-functional-prepare,start-signature-signing-and-verification"= >
=A0+  =A0 =A0<!-- now, run the actual test= -->
=A0+ =A0  =A0<junit dir=3D"." pr= intsummary=3D"yes"  haltonfailure=3D"${test.functio= nal.fail}" fork=3D"yes">
=A0+ =A0  =A0 =A0<classpath refid=3D"= classpath" />
=A0+ =A0 =A0  =A0<formatter type=3D"x= ml"  usefile=3D"${test.functional.usefile}"/>
=A0+ =A0 =A0  =A0<batchtest todir=3D"= ${test.functional.reportdir}">
=A0+ =A0  =A0 =A0 =A0<fileset dir=3D"= ${build.dest}">
=A0+ =A0  =A0 =A0 =A0 =A0<!-- Convention: = each package that's being  tested
=A0+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0has  its = own test class collecting all the tests -->
=A0+ =A0 =A0  =A0 =A0 =A0 =A0 =A0<include = name=3D"**/TestBidBuySample.class"  /> =A0+ =A0 =A0 =A0 =A0 =A0 =A0 =A0<exclude  = name=3D"**/Interop3TestCase.class"/>
=A0+ =A0 =A0 =A0  =A0</fileset><= /tt>
=A0+ =A0 =A0  =A0</batchtest>
=A0+ =A0 =A0</junit>
=A0+  =A0</target>
=A0+
=A0+
=A0 =A0 <!--  =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D  -->
=A0 =A0 <!-- Start Signature Signing and Verifi= cation  -->
=A0 =A0 <!--  =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D  -->
=A0
=A0
=A0
[IMAGE]




#### graycol.gif has been removed from this note on August 02 2002 by M= att Seibert
#### C7635590.gif has been removed from this note on August 02 2002 by = Matt Seibert= --1__=0ABBE69ADFC6DC258f9e8a93df938690918c0ABBE69ADFC6DC25-- --0__=0ABBE69ADFC6DC258f9e8a93df938690918c0ABBE69ADFC6DC25 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=0ABBE69ADFC6DC258f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBE69ADFC6DC258f9e8a93df938690918c0ABBE69ADFC6DC25--