db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: VOTE: Approach for sharing code
Date Thu, 08 Sep 2005 17:54:04 GMT
David W. Van Couvering wrote:

> I added a comment to DERBY-289
> (http://issues.apache.org/jira/browse/DERBY-289) that is my official
> proposal for an approach to sharing code.
>
For my three externals concerns, this is what I see with this proposal.

1) We need to allow mixing of client and server versions.
   This proposal theoretically achieves this but the  COMMON CLASS
CODING GUIDELINES
    seem error prone hard to manage in an open source environment and
you have to wait for those opportune moments before major releases to
refactor code.

2)  We should keep jar file growth commensurate with functionality
improvement.
    Since derby-common.jar holds all the shared classes,   it adds
footprint to the jars in many
configurations. For example, If  I just wanted the embedded server,  I
would need derby.jar + derby-common.jar which would include the drda
classes which are not needed.

3) We should try to avoid asking every user in the world to change their
classpath.
I still  think we should try to avoid it.

I liked your idea of adding just the needed classes to the  existing
jars.  The trick  is to find a way to get Derby to always load the class
from the same jar file first, then no versioning is needed.  
Suddenly, creating  separate package namespaces for the common package 
in the jars as last step of the jar build doesn't seem so weird to me. 
Obfuscators rename packages all the time and are widely accepted.
It could even happen as a special  releasejar target so it wouldn't
confuse day to day development.

Kathey



Mime
View raw message