db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: Modular build, was: VOTE: Approach for sharing code
Date Fri, 16 Sep 2005 20:48:03 GMT
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 <kmarsdenderby@sbcglobal.net> 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

Mime
View raw message