I appreciate your pragmatic approach, Andrew. The thing is I have seen
a number of other pieces of functionality queued up for code sharing
between client and server. These include DRDA network code, potentially
some higher-level JDBC functionality, logging and tracing, and
management via JMX. I also discovered that the versioning mechanism in
org.apache.derby.iapi.services.info is actually reused across tools,
client and engine.
Given this, I thought that although it would be a tough debate it was
worthwhile having and one which, if we solved, would enable a lot of
other common services to be built across client and engine. So I took
the challenge and decided to try and solve this.
We may still decide this is intractable and throw up our hands, but I
hope that's not the case. It's been a healthy debate, and has brought
to bear some good discussions about "who" we want to be, what our key
principles are, and I think that's been good too.
You talked about signing/sealing problems about packaging the classes in
multiple jars. I saw this mentioned before, can you or someone else
elaborate? If it's really true that we can't package the same classes
in multiple jars, that's a very important data point...
Thanks,
David
Andrew McIntyre wrote:
On 9/15/05, Kathey Marsden <[EMAIL PROTECTED]> wrote:
Jeremy Boynes wrote:
This dooms us forever to reinvent any functionality that could
be provided by other projects.
We are not "doomed forever". Requiring a new jar file for new
functionality seems an entirely reasonable thing to me and at that time
we can impose whatever restrictions the community sees fit. Requiring a
new jar file to have the product continue work, is another matter all
together.
+1!
It looks like we've got a really intractable situation here. There are
those against source/binary modification because of the inherent
problems with maintenance and debugging, but you can't package the
same classes in multiple jars because of signing/sealing and
classloader issues, and if you split the classes out into a new jar
then you've got usability and deployment issues. So what do you do?
I'm wondering if this is really the functionality to be considering
all of this for. Two or three small classes related to localization.
Is it really worth the trouble? Are we really going to make a common
jar file with two classes, without which you don't get error messages?
Really?
And remember, this isn't about reusing someone else's code or
libraries. I don't think anyone is going to be against reusing other
project's code or libraries in order to promote cross-project goodwill
and general open source happiness. We're talking about copying two of
our own classes from one part of the tree to the other.
I think we can all tackle the code-sharing problem with some new
functionality later. For which, by the way, I think a good candidate
would be integrating Lucene for full text indexing as a good trial for
both code reuse from other projects and code sharing among the
different parts of Derby. And personally, I'd like to see David be
able to finish localizing the error messages sometime this decade. :-)
andrew
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
