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
