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
scheme.
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).
--
Jeremy
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:
+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
