I find this arcane and confusing; worse, I don't think it really works.
Code that is using the common API becomes tied to a specific version. By
renaming the package we force all users of the common code to modify
their code. We can do that for things in our source tree but not in others.
Similarly this forces us to modify any external libraries we use to
exhibit the same behaviour - for example, renaming o.a.commons.logging
to o.a.commons.logging_1208. This means we have custom versions of all
external libraries.
Think of the carnage if it was java_14208_b13.sql_300.Connection
--
Jeremy
David W. Van Couvering wrote:
Hi, all. I've been letting this brew in my subconscious this weekend,
with the strong belief that *somehow* there is a solution that can meet
all of our requirements (simple architecture, ease-of-use,
compatibility, no regressions, easy to maintain, reduce code duplication).
I think I may have something that will do this, and your comments are
much appreciated. There is a bit of overhead for the release process,
but I think if we are going to have overhead, that's the place to do it.
The principle is that for each release, the common package is unique.
This is achieved by appending the release number to the package name. So
for the 10.1.2 release the package name is org.apache.common_1012. In
this way a consumer of the common classes for a given version is
guaranteed to load the right classes and no conflicts or confusion occur.
As part of the release process, when you make a branch for a release,
you run a script that renames the common package to match your release
name. This script does the following:
- In the source, replace all instances of org.apache.common_<oldversion>
with org.apache.common_<newversion>
- Do an svn move of java/common/org/apache/common_<oldversion> to
java/common/org/apache/common_<newversion>
Because you are using svn move, although it's a bit confusing, all
history is maintained and you can still use svn to do merges and ports
of changes.
The common package is put into both derby.jar and derby-client.jar, and
we do not create a new JAR file.
Thanks,
David
