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.
