RE: [JBoss-dev] RE: Test cases
This jar (junitejb.jar) is an ejb-jar file. JUnitEJB uses a session bean to run the test cases on the serverside. There are about a billion ways to package this. The three styles I have used follow: * An ejb-jar with a class-path ref to junit.jar in the MANIFEST-MF. * An ejb-jar with junit.jar classes included. * A jar without ejb-jar.xml or MANIFEST-MF. (assume user will handle packaging) I use the third option for my code. I create an ear with an ejb-jar that has all my beans, the test runner bean, and all test cases. The ejb-jar has a class-path ref to the junit.jar which is bundled into the ear. All of these involve coordination with the build system, because of the classpath references, or in the case of the second option, the inclusion of the junit classes could create classpath issues. Does anyone have any preferences in my release style? I'm not sure the best way to integrate this into the build process. This is why I waited so long to add my tests. -dain -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 20, 2001 12:04 AM To: David Jencks Cc: Dain Sundstrom; jboss-dev Subject: Re: [JBoss-dev] RE: Test cases Dain has en external project (on sourceforge) in sort of an alpha state that he is using to test cmp 2 stuff. What is the best way to get these tests + external stuff in? I suggest -tag other project -build jar, including some kind of info about the checkout tag. -put copy of jar in jboss thirdparty/junitejb/junitejb/lib/junitejb.jar A public release would be best, which would indicate that the source module should be tagged, though that is up to the cvs admin policy for that project. Otherwise sounds good. Is the group owner called 'junitejb'? If not then that name should be used as the vendor. Is this ok? Sure. What is the best way to indicate what version (tag in this case) the external project is at? What are we doing for the other external files? Tag the imported files with a label which indicates the version. For example the junit.jar file has a junit_3_7 tag (amoung others) which shows what version that it is: snip jason(2)reason:...thirdparty/junit/junit/libcvs status -v junit.jar === File: junit.jar Status: Up-to-date Working revision:1.1.1.1 Repository revision: 1.1.1.1 /cvsroot/jboss/thirdparty/junit/junit/lib/junit.jar,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: -kb Existing Tags: Rel_2_4_4_15(revision: 1.1.1.1) Rel_3_0_0_1 (revision: 1.1.1.1) RelMQ_1_0_0_2 (revision: 1.1.1.1) RelMQ_1_0_0_1 (revision: 1.1.1.1) RelMQ_1_0_0_0_0 (revision: 1.1.1.1) Rel_2_5_0_4 (revision: 1.1.1.1) jboss_buildmagic(branch: 1.1.1.1.4) junit_3_7 (revision: 1.1.1.1) junit (branch: 1.1.1) /snip I would suggest setting up the proper directory structre then entering the base dir (containing the lib dir and such) and doing: cvs import thirdparty/junitejb/junitejb junitejb junitejb_M_m_r Where M_m_r is the Major.minor.release or whatever the vendor (dain) descides to use as a convetion for release numbers. This will setup the correct tags. Be sure to inclde a LICENSE file as a peer to lib/ to indicate its distribution licensing too. * * * Tagging is the only way I have found with CVS to tack this version information. If someone else has an idea on how todo it better please let me know. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: Test cases
On 2001.11.19 16:35:48 -0500 Dain Sundstrom wrote: Comments below (changed subject to reflect new discussion thread) snip Is this structure imposed by the build system or is it just a convention? Looking more closely, anything named *UnitTestCase and not specifically excluded will be run in tests-unit. Put as many directories as you want in. I have a set of test that are based on the cmp 2 section 10.3.7 Assignment rules for relationships of the ejb 2.0 spec. There are test for each relation type (1-n bi, 1-n uni, n-1 uni ...) and mapping style (fk, fk with back pointers, and relation-table). That is about 14 unit tests. Anyway I have these organized into sub-packages under the org.jboss.test.relationship package. I can't merge them all into package as each type has it's own set of 'A' / 'B' interfaces. Should I leave them organized into sub packages or should I eliminate the top level relationship package? The other issue I have is my tests use a, yet to be completed, extension to JUnit which runs the tests on the serverside (I wrote this). This is required for testing local interfaces which by definition are not accessible remotely. Anyway, how do I go about adding the code to the build system. It is in the package net.sourceforge.junitejb.* This is on sourceforge in its most recent state? I'd add the jar into thirdparty/junitejb/junitejb/lib/junitejb.jar with a readme saying what version it is. I'd think tagging cvs when you make the jar would be a very good idea. You might want to ask Jason first. david -dain ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: Test cases
The other issue I have is my tests use a, yet to be completed, extension to JUnit which runs the tests on the serverside (I wrote this). This is required for testing local interfaces which by definition are not accessible remotely. Anyway, how do I go about adding the code to the build system. It is in the package net.sourceforge.junitejb.* This is on sourceforge in its most recent state? I'd add the jar into thirdparty/junitejb/junitejb/lib/junitejb.jar with a readme saying what version it is. I'd think tagging cvs when you make the jar would be a very good idea. You might want to ask Jason first. I have to update the cvs for my project. I just changed it with the cmp2 doc example code. The I'll package and post the package. I'll also tag the cvs version. If Jason is listening, do you have any comments on this? -dain ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: Test cases
snip Is this structure imposed by the build system or is it just a convention? Looking more closely, anything named *UnitTestCase and not specifically excluded will be run in tests-unit. Put as many directories as you want in. This is a change in main then. I think we should keep the previous convention of having a single directory per suite of tests that contain all the unit test classes. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RE: Test cases
I haven't been following this thread at all... just happened to see my name at the bottom on this one. What is the issue? The short version please =) --jason On Mon, 19 Nov 2001, Dain Sundstrom wrote: The other issue I have is my tests use a, yet to be completed, extension to JUnit which runs the tests on the serverside (I wrote this). This is required for testing local interfaces which by definition are not accessible remotely. Anyway, how do I go about adding the code to the build system. It is in the package net.sourceforge.junitejb.* This is on sourceforge in its most recent state? I'd add the jar into thirdparty/junitejb/junitejb/lib/junitejb.jar with a readme saying what version it is. I'd think tagging cvs when you make the jar would be a very good idea. You might want to ask Jason first. I have to update the cvs for my project. I just changed it with the cmp2 doc example code. The I'll package and post the package. I'll also tag the cvs version. If Jason is listening, do you have any comments on this? -dain ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RE: Test cases
On 2001.11.19 18:22:59 -0500 Jason Dillon wrote: I haven't been following this thread at all... just happened to see my name at the bottom on this one. What is the issue? The short version please =) --jason Dain has en external project (on sourceforge) in sort of an alpha state that he is using to test cmp 2 stuff. What is the best way to get these tests + external stuff in? I suggest -tag other project -build jar, including some kind of info about the checkout tag. -put copy of jar in jboss thirdparty/junitejb/junitejb/lib/junitejb.jar Is this ok? What is the best way to indicate what version (tag in this case) the external project is at? What are we doing for the other external files? thanks david jencks On Mon, 19 Nov 2001, Dain Sundstrom wrote: The other issue I have is my tests use a, yet to be completed, extension to JUnit which runs the tests on the serverside (I wrote this). This is required for testing local interfaces which by definition are not accessible remotely. Anyway, how do I go about adding the code to the build system. It is in the package net.sourceforge.junitejb.* This is on sourceforge in its most recent state? I'd add the jar into thirdparty/junitejb/junitejb/lib/junitejb.jar with a readme saying what version it is. I'd think tagging cvs when you make the jar would be a very good idea. You might want to ask Jason first. I have to update the cvs for my project. I just changed it with the cmp2 doc example code. The I'll package and post the package. I'll also tag the cvs version. If Jason is listening, do you have any comments on this? -dain ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RE: Test cases
Dain has en external project (on sourceforge) in sort of an alpha state that he is using to test cmp 2 stuff. What is the best way to get these tests + external stuff in? I suggest -tag other project -build jar, including some kind of info about the checkout tag. -put copy of jar in jboss thirdparty/junitejb/junitejb/lib/junitejb.jar A public release would be best, which would indicate that the source module should be tagged, though that is up to the cvs admin policy for that project. Otherwise sounds good. Is the group owner called 'junitejb'? If not then that name should be used as the vendor. Is this ok? Sure. What is the best way to indicate what version (tag in this case) the external project is at? What are we doing for the other external files? Tag the imported files with a label which indicates the version. For example the junit.jar file has a junit_3_7 tag (amoung others) which shows what version that it is: snip jason(2)reason:...thirdparty/junit/junit/libcvs status -v junit.jar === File: junit.jar Status: Up-to-date Working revision:1.1.1.1 Repository revision: 1.1.1.1 /cvsroot/jboss/thirdparty/junit/junit/lib/junit.jar,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: -kb Existing Tags: Rel_2_4_4_15(revision: 1.1.1.1) Rel_3_0_0_1 (revision: 1.1.1.1) RelMQ_1_0_0_2 (revision: 1.1.1.1) RelMQ_1_0_0_1 (revision: 1.1.1.1) RelMQ_1_0_0_0_0 (revision: 1.1.1.1) Rel_2_5_0_4 (revision: 1.1.1.1) jboss_buildmagic(branch: 1.1.1.1.4) junit_3_7 (revision: 1.1.1.1) junit (branch: 1.1.1) /snip I would suggest setting up the proper directory structre then entering the base dir (containing the lib dir and such) and doing: cvs import thirdparty/junitejb/junitejb junitejb junitejb_M_m_r Where M_m_r is the Major.minor.release or whatever the vendor (dain) descides to use as a convetion for release numbers. This will setup the correct tags. Be sure to inclde a LICENSE file as a peer to lib/ to indicate its distribution licensing too. * * * Tagging is the only way I have found with CVS to tack this version information. If someone else has an idea on how todo it better please let me know. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
