Kathey Marsden wrote:
David Van Couvering (JIRA) wrote:
I'd like to revisit our beloved issue of code sharing.
[snip details on code sharing proposal that does not negatively impact
users. Hooray!]
I personally prefer an approach similar to the obfuscation tools, where
1) All the code imports the checked in files and is built to the
classes directory as normal. Just as if we had no code sharing concerns.
Developers can point to the classes and debug and edit as normal.
2) In the jar build, after building the classes the code is copied and
modified as needed to create a separate name space under production/java
and then built to production/classes. The jars are built from
production/classes. For running derbyall developers are instructed to
point to the jars to catch any troubles in this process.
Hi, Kathey. When you say the "code is copied and modified as needed"
what exactly are you thinking of here. Is this byte-code modification,
or are you proposing a source-code copy/modify. If the latter, wouldn't
this require also modifying all classes depending upon the shared
classes to use the new package name?
I don't know how obfuscation works, but I think this is a byte-code
change, right? I'll go take a look at obfuscation tools to get a sense
of what they do.
Maybe some of the newer obfuscation tools have something more clever,
but since essentially what we are doing is obfuscating these classes so
they don't conflict , I think this might be a good approach that will
impact developers less. The only downside I see is build time when
building jars, but that will be required only before running tests.
Well, the other downside is that when you get a stack-trace, you won't
be able to find the source referred to in the trace, and you have to
manually translate to the actual classes. That's one of the things I
disliked about obfuscators -- what the heck is a.b.c.Connection.x()?
This is similar with the approach I proposed, except that the generated
classes are still around, and for instance in an IDE you can
double-click and get taken directly to a source file to inspect, even if
it's not the source file you should ultimately be modifying.
I certainly won't put up a fight if we do it the other way, but just
thought I would throw this out there again.
Thanks for your interest and participation, this is a tough nut to crack.
David
Kathey
