So I guess we are in agreement about having a "common" dir for the client and server parts - I'm also interested in seeing this happening for some work am currently doing. As Satheesh mentioned we would still package "common" classes in both jars for now...
--francois On 8/17/05, Rick Hillegas <[EMAIL PROTECTED]> wrote: > Hi Satheesh, > > I also am in favor of redundantly packaging these classes in the > existing jar files and not creating a new jar file. Admittedly, this > could use some more discussion. I agree with you that this simplifies > setup for our users. I'm a big fan of simplifying the customer's first > experience with Derby. I think it helps sell the technology. > > Cheers, > -Rick > > Satheesh Bandaram wrote: > > >Dan is still on vacation and is expected next week, I think. We may be > >able to start sharing code by refactoring things like these, but we > >could still continue to package these classes in both JARs. This would > >allow us to not duplicate code, still keeping the same JARs. When this > >common code crosses a critical mass, may be we could revisit the idea of > >breaking into a common jar. > > > >Having another JAR makes setup more involved (for end users) and need to > >address multiple different version issues... but this would allow us to > >start sharing code now. Just a suggestion.. > > > >Satheesh > > > >Rick Hillegas wrote: > > > > > > > >>Hey Dan, > >> > >>I'm going to hold off on this until you get back. It would be nice to > >>work out a code-sharing model soon. My particular issue here is that I > >>want to add some new constants to the network layer and it seems > >>brittle to me to have to make identical edits in two sets of files. > >> > >>Cheers, > >>-Rick > >> > >>David Van Couvering wrote: > >> > >> > >> > >>>You go, Rick! I think the edge case is going to bite you, though. I > >>>don't think you can wave your hands and say customers can just write > >>>a classloader to fix the problem. > >>> > >>>If I remember correctly, the motivation for the edge case was to > >>>allow different versions of the network driver and embedded driver > >>>running next to each other. > >>> > >>>I think this was motivated by some IBM customers. My questoin is: is > >>>the real motivation for compatibility between client and server? If > >>>so, it seems to me that what you really want is for a new version of > >>>the network client driver to be backward compatible with an older > >>>version of the server running elsewhere, or, vice-versa, a newer > >>>version of the server to be backward compatible with an older version > >>>of the client. This was managed at Sybase with the TDS protocol > >>>using a handshake at login time where the client and server agree at > >>>what version of the protocol to run at. Perhaps this is what we want > >>>to do here. > >>> > >>>If the motivation was something else, I'd like to understand it > >>>better. Dan D. was the main person who brought this up. Is Dan back > >>>yet? > >>> > >>>Thanks, > >>> > >>>David > >>> > >>>Rick Hillegas wrote: > >>> > >>> > >>> > >>>>When we last visited this issue (July 2005 thread named "Size of > >>>>common jar file"), we decided not to do anything until we had to. > >>>>Well, I would like to start writing/refactoring some small chunks of > >>>>network code for sharing by the client and server. My naive approach > >>>>would be to do the following. > >>>> > >>>>o Create a new fork in the source code: java/common. This would be > >>>>parallel to java/client and java/server. > >>>> > >>>>o This fork of the tree would hold sources in these packages: > >>>>org.apache.derby.common... > >>>> > >>>>o The build would compile this fork into > >>>>classes/org/apache/derby/common/... > >>>> > >>>>o The jar-building targets would be smart enough to include these > >>>>classes in derby.jar, derbyclient.jar, and derbytools.jar. > >>>> > >>>>As I recall, there was an edge case: including a derby.jar from one > >>>>release and a derbyclient.jar from another release in the same VM. I > >>>>think that a customer should expect problems if they mix and match > >>>>jar files from different releases put out by a vendor. It's an old > >>>>deficiency in the CLASSPATH model. With judicious use of > >>>>ClassLoaders, I think customers can hack around this edge case. > >>>> > >>>>I welcome your feedback. > >>>> > >>>>Cheers, > >>>>-Rick > >>>> > >>>> > >>> > >>> > >>> > >> > >> > >> > > > > > > > >
