David W. Van Couvering wrote: > BUILDING THE COMMON PACKAGE > > The build script for the org/apache/derby/common directories > will not compile the class. Instead, it invokes a build-time > tool that will perform the following actions for each class > in the org/apache/derby/common hierarchy: >
Thinking of this in the same light as an obfuscator, I sort of thought of the rename/copy coming much later and only for the jar build. So in your example when the developer added java/common/org/apache/derby/common/logging/Logging.java, she would just import org.apache.derby.common.logging.Logging where needed. Instead of looking like a regular class it is a regular class. The default ant (all) target it would just get built as you would expect. The IDE's would behave and there are no extra confusing copies. The jar build (buildjars) target is where the change happens. PREFERRED OPTION The jars are built normally and then afterwards some utility runs on the binaries to rename the package, For example the utility changes org.apache.derby.common.* -> org.apache.derby.client.common.* in derbyclient.jar. I have no idea how hard this is to make such a uitility, but was once told that such utilities exist. Perhaps someone with more Java bytecode knowledge than I could tell us how hard. ALTERNATE OPTION In the jar build an alternate source code tree is generated in the jar build location, which 1) Generates java/common/org/apache/derby/client/common/*, java/common/org/apache/derby/engine/common/*, java/common/org/apache/derby/tools/common/* java files. 2) Fixes up the imports for the other java files. 3) Builds the new source tree and makes the jars. ISSUES - - The jar build takes more disk space, and becomes more mysterious, especially for the ALTERNATE OPTION, - User reported stack traces will show classes that only exist for the jar build, which might be a bit confusing to developers, but README files in the generated directories in the source tree could mitigate this. Kathey
