Copying common classes to specific (tier) packages does sound good - However, it is true that there could be confusion during development and debugging if the engine and client common classes are not up to date (did not get re-generated) and if some developers do not necessarily understand how the 'common' package is managed in the codeline.  I guess this is true for some other packages we have but this one is going to be fairly visible due to the fact we are sharing code functionality here between 2 tiers.

Due to the requirement of supporting a different version of the derby client and server in the same JVM, it's not like there are a lot of other and simpler alternatives out there indeed...Am guessing we're not going to support the loading of 2 different DerbyClient versions in the same JVM...(although one could envision db2jcc.jar and DerbyClient.jar running in the same JVM...we should not be seeing any conflict if the package structure is different)

--francois


Reply via email to