Kathey Marsden wrote:
> > 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. I've been thinking about suggesting that as well, e.g. the same code would be generated into two source java files in two (etc.) packages: org.apache.derby.engine.common org.apache.derby.client.common As I said in an earlier e-mail, you can share at many levels, a lot depends on why you are sharing? Is it to reduce development effort, reduce static/runtime footprint, add confusion for the user? > Obfuscators rename packages all the time and are widely accepted. And we already have generated code, so we handle that currently, ie. the java files from the parsers. > It could even happen as a special releasejar target so it wouldn't > confuse day to day development. I don't agree with this, a single build process is much better, it nmeans the normal development testing is in line with the released builds. Dan.
