You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kathey Marsden (JIRA)" <de...@db.apache.org> on 2005/08/17 18:37:54 UTC
[jira] Commented: (DERBY-289) Enable code sharing between Derby client and engine
[ 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-289) Enable code sharing between Derby
client and engine
Posted by David Van Couvering <Da...@Sun.COM>.
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.
>>>
>>>
>>
>>
>>
>
>
Re: [jira] Commented: (DERBY-289) Enable code sharing between Derby
client and engine
Posted by Rick Hillegas <Ri...@sun.com>.
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.
>>
>>
>
>
>