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
- Re: VOTE: Approach for sharing code Francois Orsini
- Re: VOTE: Approach for sharing code Jeremy Boynes
- Re: VOTE: Approach for sharing code Francois Orsini
- Re: VOTE: Approach for sharing code Daniel John Debrunner
- Re: VOTE: Approach for sharing code David W. Van Couvering
- Re: VOTE: Approach for sharing code David W. Van Couvering
