+1. I also vote to solve the common code issues when we have sufficient critical mass of it. Currently there doesn't seem to be enough to justify a new mechanism, especially a solution that is directly visible to end users and could cause some disruptions. While the discussion has been very useful to evolve a possible solution in the future, I don't see an urgent need to address this yet. Not sure how end-users would see a derbycommon.jar that is only a few kilobytes (tens?) in size and wonder why it is even there.
We just released a 10.1 feature release... Not sure when our next feature release is going to be, but seems like there might be many months of time to address any packaging issues. Let us continue to enhance Derby in the current framework and as we get closer to another release, we could evaluate the packaging issues. Evolution, not revolution... Someone said this before, don't remember who ... :-) Satheesh Andrew McIntyre wrote: >+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 > > > > >
