On Dec 22, 2005, at 7:18 AM, Tim Ellison wrote:
Does anyone have an opinion about where JUnit tests should be stored
under enhanced/classlib/trunk/ ? These will be new tests for bug
fixes etc.
The current layout looks like this, with a couple of options marked:
enhanced/classlib/trunk/
depends/ <- 3rd-party stuff + some resources
doc/ <- doxygen output
java-src/
archive/
src/ <- java code for archive component
<<option-1>>
native-src/
linux.IA32/ <- linux native code
win.IA32/ <- windows native code
<<option-2>>
I don't have a strong feeling either way.
<<option-1>> says put the unit tests into a folder alongside the
implementation of each component of the class library (archive, math,
etc.) That way the tests live with the implementation, and there is a
good incentive for the two to be maintained simultaneously. It does,
however, make the packaging a bit more interesting because the tests
have to be separated -- this is not a big deal though.
This is sort of the way I'm familiar with, but a little different to
ensure that all tests are in a separate tree. This is closer to your
option 2.
I mean :
java-src/
src/
archive/
org/
apache/
harmony/
classlib/
archive/
Foo.java
luni/ <- peer to archive...
net/
...
test/ <- peer to src
archive/
org/
apache/
harmony/
classlib/
archive/
TestFoo.java
luni/
net/
It's fairly easy to handle when packaging as you can package the
entire test/ tree separate from src/ w/ no problems. It's also a
fairly common convention around here - the only diff from what I've
worked with in the past is there is a module-like architecture w/o
java-src, namely the segmentation by archive, net, luni, etc.
What I'm used to, using the names we have is something like
modules/
luni/
src/
java/
test/
archive/
src/
java/
test/
net/
src/
java/
test/
In our case, we have the complication of native code as well. Does
it make sense to commit completely by module, where each module is
has all the java, multi-platform native and test code under one root
in the tree?
modules/
luni/
src/
java/
src/
test/
native/
win32/
src/
test/
linux32/
src/
test/
osX/
src/
test/
archive/
src/
java/
src/
test/
native/
win32/
src/
test/
linux32/
src/
test/
osX/
src/
test/
And module is every module that we have, like port, launcher, etc.
Some don't have Java, but that's ok - you get a very good high-level
view of the produced artifacts by looking in the modules directory.
modules/
archive/
luni/
io/
math/
launcher/
port/
whatever we come up with.
Also, it means that if a module has some specific build need, that is
handled right there by the build config w/in the module - the build
for the classlib is a top level that kicks off each module in a
standard way, but then each module build is specific to the module.
Otherwise, we need a global all-knowing build that spans all modules,
which sounds like we could run into maintenance problems in the future.
It also means any special test framework for a module is also the
business of just that module.
What do you thinK?
<<option-2>> says put the tests into a parallel hierarchy at the same
level as the java and native code, e.g.
.../trunk/java-tests/archive/src/ and so on. This makes the packaging
of the tests simpler since they are out of the way and allows us to
treat them as separate components.
FWIW: I see that the HARMONY-16 contribution has the equivalent of
<<option-2>>.
Thoughts?
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
