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/lib>cvs 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
