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
