I'm uncomfortable with the "build trick" -- it feels like a hack. Let's think about this some more.
David Rick Hillegas wrote: > Yeah. I don't have any clever ideas. The "build trick" would be fairly > easy to implement. If this turns out to be the consensus of the group, I > can do this work. But I'd like to understand how we can reduce the > confusion which this will cause new developers. > > -Rick > > Kathey Marsden (JIRA) wrote: > > >> [ >> http://issues.apache.org/jira/browse/DERBY-289?page=comments#action_12319057 >> ] >> >>Kathey Marsden commented on DERBY-289: >>-------------------------------------- >> >>The biggest concern for me is upgrade in server configurations where both the >>client and server are in the classpath. See the upgrade scenario in the >>previous comment. >> >>I think taking away the ability to mix versions and requiring users to >>judiciously use ClassLoaders in order to upgrade is not reasonable, >>especially when the reason for the change cannot be explained in terms of any >>functionality improvement. >> >>I think >> >>- We need to allow mixing of client and server versions, both on a protocol >>level and in the same classpath. >>- We should keep jar file growth commensurate with functionality improvement. >>- We should try to avoid asking every user in the world to change their >>classpath. >> >>For code sharing now, I think constants would be a great place to start since >>they get compiled out. >> >>For other code, it seems to me that we will need either some stable internal >>API (hard to manage) or some build trick to create a client jar with a >>separate package namespace for the common code (weird because the classes in >>the stack traces would be a little different than the actual code). That's >>all I have in the way of ideas, but know I really don't want to see us loose >>the ability to mix client and server versions. >> >> >> >> >> >> >>>Enable code sharing between Derby client and engine >>>--------------------------------------------------- >>> >>> Key: DERBY-289 >>> URL: http://issues.apache.org/jira/browse/DERBY-289 >>> Project: Derby >>> Type: Improvement >>> Components: Network Client >>> Versions: 10.0.2.1, 10.0.2.0, 10.0.2.2, 10.1.1.0 >>>Environment: N/A >>> Reporter: David Van Couvering >>> Priority: Minor >>> Fix For: 10.2.0.0 >>> >>> >> >> >> >> >>>Right now, there is no way for the Derby network client to share code with >>>the Derby engine. We should have a separate jar file, e.g. >>>derby_common.jar, that contains shared code and is used by both the client >>>and the engine. >>> >>> >> >> >> > >
