[Objectbridge-developers] XML used in test.ojb.server, etc

[Thomas M. <tho...@ho...>]

Hi David,

I hope you had a nice christmas and wish you the best for the new year!
I've used my christmas vacation for relaxing and for working a little on
improving the PersistenceBroker. It's now quite complete and really
quite fast.
I thinks its ready to be used within heavy duty applications.

So once this is mostly finished I'd like to spend more time on the ODMG
stuff. I hope we find a solution to split the work in order not to
"stand on each others toes". Maybe I could grasp something that you are
not currently working on, e.g OQL, or reworking the
ojb.examples.server.App to work with all the new features...

I've 2 questions regarding your test.ojb.server package:
1. You seem to use the XERXES parser, I don't get the code compiled
against the jaxp.jar and parser.jar containing the the JAXP api and the
standard sun parser.
Do you need any specific features that only Xerxes provides? If not I'd
suggest not to use it, as the jar is quite big and we have the comple
JAXP jar already in our distribution.
If you think we need xerxes I have no objection but then please check in
all nesseccary things into CVS. 
2. In class test.ojb.server.StateMachineTest there are references to
types "TransitionDoesntMatch" and "TestStateUnreachable". I could not
find those types in CVS?

This did not make any problems with my work on the PersistenceBroker,
but I had some trouble in getting the new release 0.1.41 built.
The target "release" depends on the "main-opt" target which tries to
compile all classes under src.
I could only build the 0.1.41 release by excluding the test.ojb.server.*
classes from the main-opt target...

This is no drama but as a general means of quality assurance it's a good
thing only to build a release when all the sources do compile.

I try to minimize problems with builds and CVS conflicts using the
following checklist:
On my development machine (NT):
1. develop my code with VisualAge 3.5, run all JUnit tests.
2. run the build junit and build release

On the build machine (Linux)
3. running cvs update -d to check if someone made changes to files I've
also been working on
4. placing my modified files in the according place
5. running build.sh junit and build.sh release
6. running cvs commit
7. if cvs complain about unknown (i.e. newly added files) check them in
with cvs add
8. if I moved or deleted some stuff remove it with cvs remove
9. call cvs commit again and check if there are still some ?
10. call cvs update -d if I'm still in sync with the repository.

I think using this or a similar scheme we can reduce problems in the
build process.

I think it would be a good idea to be even more rigid and make the
"release" target dependend on the "junit" target to express our firm
believe in Unit testing: "No release without successful regression
testing".

Best regards,

Thomas