Don't know if I have the best answers, but I'll i'll try my best...
On Oct 5, 2006, at 8:21 PM, Prasad Kashyap wrote:
Can someone please shed some light on it
and help me understand the present structure ?
There are actually two different structures there.
Structure One
openejb-itests
There are some 21 beans 400 tests in this bucket. The test suite is
divided into four sections; stateful, stateless, cmp (1.x), bmp. The
tests in each section follow a pattern of starting simple and growing
in complexity and are in logical order as much as possible. For
example, we test JNDI before we test that you can lookup a bean and
use it's create method. We try not to put the cart before the horse
so that if something does break, you get as far though the test suite
as possible before you encounter the breakage (rather than the very
first test). It's not uncommon for tests to break while refactoring.
Structure Two
scenario1
scenario2
scenario3
cmp2-prefetch
cmp2-petstore
cmp2-storage
cmp2-cmrmapping
These are security and cmp2 tests. The cmp2 tests may easily be able
to be folded into openejb-itests, which does not have and needs a
cmp2 section. Dunno, haven't looked at them too much. The security
tests (scenario1,2,3) use pretty much the same beans but configured
with different plans (IIUC). Alan and Gianny could probably fill in
more details on those.
Now, are these java files disjoint enough that they can be split apart
into as many projects as the ejb archives we need ?
I think they may group together like such:
openejb-itests
scenario1
scenario2
scenario3
cmp2-prefetch
cmp2-petstore
cmp2-storage
cmp2-cmrmapping
Don't know about the cmp2 tests, but the security tests definitely
reuse the same classes.
Don't think we can
build all the classes in one core m2 project and use the classes in
another project which has just the plan DD. Can we ?
Ejbs can use third part jars, so yes. The bean classes and other
classes don't actually have to be inside the same jar as the ejb-
jar.xml and plan. The plan for that matter doesn't have to be in the
jar at all.
Is the openejb-itests archive really needed ? It is the one big
archive for the whole project that encompasses everything. It has it's
own plan and DD and is also distributed into the server. But it also
contains the other archives. This is kinda confusing.
The openejb-itests archive doesn't contain any other archives. The
module does which is probably what you meant. As noted above, those
other archives could likely go into their own modules.
Dunno if I really answered your question.
I believe the test java files are in src/itest directory. However,
they have a dependency on the java files in src/java.
IIRC, I think the ejbs themselves are in src/java and the client code
(the unit tests) are in src/itests.
Like I said, the
only a subset of files in src/java are used to create archives. The
rest are either included in that big openejb-itests archive or simply
needed to support the junit tests in src/itests. Now why is it
structured this way ? Why weren't they moved to the src/itests dir
where they are needed ?
The beans need to get packaged and deployed into the server. The
itests themselves could be run from maven ( no need to archive them
really unless you want to run them again as tests in another maven
module )
In reference to OpenEJB 3, which I guess is unlikely to be the way
Geronimo structures it's tests, the itests are in one module as a
plain ejb app. We then deploy and test sever modules with them by
declaring a dep on them with 'test' as the scope and then create
JUnit TestSuite instances to essentially import the tests we want to
run. I think we run the itests about 8 times total.
[INFO] OpenEJB :: iTests .....................................
SUCCESS [3.739s]
[INFO] OpenEJB :: Container ..................................
SUCCESS [0.015s]
[INFO] OpenEJB :: Container :: Loader ........................
SUCCESS [0.394s]
[INFO] OpenEJB :: Container :: Java EE .......................
SUCCESS [2.513s]
[INFO] OpenEJB :: Container :: Core ..........................
SUCCESS [23.354s] (itests run 3 times)
[INFO] OpenEJB :: Container :: Persistence ...................
SUCCESS [7.373s]
[INFO] OpenEJB :: Server .....................................
SUCCESS [0.015s]
[INFO] OpenEJB :: Server :: Client ...........................
SUCCESS [1.593s]
[INFO] OpenEJB :: Server :: Core .............................
SUCCESS [2.155s]
[INFO] OpenEJB :: Server :: EJBd .............................
SUCCESS [7.176s] (itests run 2 times)
[INFO] OpenEJB :: Server :: Admin ............................
SUCCESS [1.827s]
[INFO] OpenEJB :: Server :: Http .............................
SUCCESS [8.466s] (itests run 2 times)
[INFO] OpenEJB :: Server :: Telnet ...........................
SUCCESS [2.324s]
[INFO] OpenEJB :: Server :: XFire ............................
SUCCESS [1.627s]
[INFO] OpenEJB :: Server :: Axis .............................
SUCCESS [2.207s]
[INFO] OpenEJB :: Server :: CORBA ............................
SUCCESS [2.751s] (not yet, but soon)
[INFO] OpenEJB :: Examples :: HelloWorld Stateful Pojo .......
SUCCESS [3.776s]
[INFO] OpenEJB :: Examples ...................................
SUCCESS [0.009s]
Guess that's only 7. If you build with assemblies profile '-
Dassemble=true' you'll get three more modules and can run the itests
another 5 times. In these modules we do it in maven1 still as we use
ant/jelly to unpack our zips and stuff and run the tests against the
final assemblies.
Not sure if that info helps what you're working on. Let me know.
-David
