db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: Modular build, was: VOTE: Approach for sharing code
Date Fri, 16 Sep 2005 22:16:10 GMT
Evolution would start with a small change that was then built on and 
expanded. From that perspective, starting with a small change like the 
localization would be the beginning of an evolutionary change. Doing it 
now, near the start of a feature release, and providing plenty of time 
for feedback from users in the community is less disruptive than trying 
to rush it in at the end.

This is one area where open source is different than closed source 
development - all users get to see changes early and can provide 
feedback into the process, not just a selected few during a beta cycle 
when it is usually far to late.

As for the size of the common jar, once you go beyond one adding 
additional libraries in becomes just more of the same. That leads to a 
model where packaging is based on loose vs. close coupling 
considerations. Some services may be small, some may be larger, but the 
boundaries are determined by the use case and not an arbitrary packaging 

This was an issue originally with Jakarata Commons. In its early days, 
although the libraries were separated out from the original monolith 
they were still coupled together; it wasn't until later that the 
decoupling of services we have now was attained (and to some extent that 
is still a work in progress).


Satheesh Bandaram wrote:
> +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:
>>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?
>>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. :-)

View raw message