[
http://issues.apache.org/jira/browse/DERBY-289?page=comments#action_12415429 ]
David Van Couvering commented on DERBY-289:
-------------------------------------------
Now that the i18n work is pretty much done and the 10.1.3 release is
closed, I'd like to revisit our beloved issue of code sharing.
I have had time to think about this further, and believe it or not I
am warming to Kathey's proposed approach. I'd like to propose a
refinement to this here, and get your feedback.
I'd like to desribe the proposal in terms of an example. Let's say
we have a class we want to share between derbyclient jar and
derby.jar, called DavidUtil. Here's how I would share it.
(a) Create the class under the shared package hierarchy (or move
it if it is an existing class. Yes, yes, I know it needs
copyrights and javadoc :)
package org.apache.derby.shared.common;
public class DavidUtil {
public int foo(int a, int b) {
// code here
}
}
(b) Add an ant target that takes all classes under
org.apache.derby.shared and makes a copy of them under
org.apache.derby.shared.generated.client. This would need
to be done prior to any compilation.
Yes, I know the package name is a mouthful, but we really should
have the "generated" package name to make it clear this is generated
code. The alternative is to add a comment, but then the line numbers
are out of sync between generated and original code, and this makes
debugging very difficult.
If we also want to create shared classes for derbynet and
derbytools, we would create copies there too. For example:
package org.apache.derby.shared.generated.client.common;
public class DavidUtil {
public int foo(int a, int b) {
// code here
}
}
==
package org.apache.derby.shared.generated.net.common;
public class DavidUtil {
public int foo(int a, int b) {
// code here
}
}
==
package org.apache.derby.shared.generated.tools.common;
public class DavidUtil {
public int foo(int a, int b) {
// code here
}
}
Although this needs to be tested and verified, The 'generated' directory
would be marked as a directory to be ignored by subversion using the
svn:ignore property. This way these files would not show up under
svn status as "?" and could not be checked in by accident.
(c) In the engine code (e.g. the classes that go into derby.jar),
I import org.apache.derby.shared.common.DavidUtil.
In the client code I import
org.apache.derby.shared.generated.client.common.DavidUtil
and so on...
(d) During runtime, the stack trace on the client will show
the generated class. The line numbers should match because
we're not adding or removing any lines, just modifying the
package name.
ADVANTAGES
- Meets all the requirements of shared code. Each jar has a distinct
and separate class. There is no potential for shadowing and
compatibility issues in mixed-version environments.
- Simple to implement and fairly simple understand (my concern about
the classloader solution has been its overall complexity and that it
would require most developers to understand the subtleties of
classloading to be able to work with parts of Derby).
DISADVANTAGES
- Potential of confusion for developers who try to modify
generated code or add new classes to the generated packages.
This is mitigated by the "generated" part of the package name
and the fact that the generated directories are ignored by
subversion.
- Doesn't solve the more general problem of being able to include
third-party jar files and share them between derby jar files
in a mixed-version environment. I would argue this
is a different problem to solve and less urgent than sharing code
within Derby itself.
Your thoughts are most appreciated.
Thanks,
David
> Enable code sharing between Derby client and engine
> ---------------------------------------------------
>
> Key: DERBY-289
> URL: http://issues.apache.org/jira/browse/DERBY-289
> Project: Derby
> Type: Improvement
> Components: Network Client
> Versions: 10.0.2.1, 10.0.2.0, 10.0.2.2, 10.1.1.0
> Environment: N/A
> Reporter: David Van Couvering
> Assignee: David Van Couvering
> Priority: Minor
> Fix For: 10.2.0.0
> Attachments: DERBY-289.diff
>
> Right now, there is no way for the Derby network client to share code with
> the Derby engine. We should have a separate jar file, e.g. derby_common.jar,
> that contains shared code and is used by both the client and the engine.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
