RE: [Unverified Sender] RE: [juddi-Developers] Wot no gump nag? ; -)

["Viens, Steve" <St...@FMR.COM>]

Forgot to mention how it relates to Gump (but you can probably guess).

The Gump build should run the TestAll test suite but not the TestInterop
test suite.

-----Original Message-----
From: Viens, Steve 
Sent: Tuesday, August 05, 2003 11:46 AM
To: 'juddi-developers@lists.sourceforge.net'
Subject: [Unverified Sender] RE: [juddi-Developers] Wot no gump nag? ;-)


"Finally, if we can have some unit tests that have no environment dependency
we can add a second project for those."

The 'handler' JUnit tests that Anou was working on will fit this
description. 

This is how I'd like to deal with JUnit testing and Gump (tell me what you
think):

1. The packages focused on testing UDDI4j and JUDDIProxy interoperability
(org.juddi.junit.uddi4j and org.juddi.junit.proxy respectively) will be
included in a new 'testinterop' target. A new 'root' TestInterop.java class
will be added to the "org.juddi.junit" package that only invokes these two
test suites. Perhaps a JAXR test suite would be a nice addition to this as
well.

2. The JUnit tests the do not require an environment setup will remain the
focus of the 'test' target. The TestAll.java class in "org.juddi.junit" will
only invoke the test suites that do not require an environment ... such as
the Handler JUnit tests mentioned above.

Also, I'm open to the idea of leaving piecemeal JUnit tests sprinkled
throughout the code (I thiink Adam mentioned this a while back). I just
wanted to be sure to have a comprehensive collection of formal JUnit test
suites as well.

Please feel free to comment...

Steve

-----Original Message-----
From: Adam Jack [mailto:ajack@trysybase.com] 
Sent: Tuesday, August 05, 2003 11:09 AM
To: juddi-developers@lists.sourceforge.net
Subject: [juddi-Developers] Wot no gump nag? ;-)


The xerces addition did it:	:-)

	http://cvs.apache.org/builds/gump/latest/juddi.html

So, now we'll get nightly builds (whenever the stack below builds first)
that ensure that jUDDI keeps pace with the tools it depends upon, and also
that the code is CVS builds nightly. A useful

I just noticed we do have one small problem for anybody depending upon
jUDDI:

This was a bad habit I have, we ought uncomment these two -- they tell gump
where to find stuff.
	<!-- Work dirs to be included in classpath -->
	<!-- work nested="build/classes"/-->
	<!--home nested="build"/-->

Also, this:
	<jar name="juddi-@@DATE@@.jar"/>

Tells gump to "look for" a jar called juddi-`date`.jar, and the build.xml
isn't building this. What I usually do is add a copy to the gump task (after
the jar task has run). Without this fixed, any code that tries to <depend
name="juddi" will fail with "missing dependency" even if juddi succeeds.

Finally, if we can have some unit tests that have no environment dependency
we can add a second project for those.

I will work with Anou on these changes.

regards

Adam
--
<http://www.try.sybase.com>
Experience Sybase Technology ...



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
juddi-developers mailing list
juddi-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/juddi-developers


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
juddi-developers mailing list
juddi-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/juddi-developers