db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: Modular build, was: VOTE: Approach for sharing code
Date Thu, 15 Sep 2005 16:15:42 GMT
Jeremy Boynes wrote:

>
> Let's recharacterize this a little. What we are contemplating with
> code sharing is extracting common functionality out into a library. By
> saying that we are not willing to accept any solution where a
> component depends on a library we are shutting ourselves off from
> using any external library or any functionality not provided by Derby
> itself. 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.

We can deprecate product functionality that we don't like for some
reason, but we can't just up and one day take away something that
deployed products depend upon.   There are products that are out in the
field now which support and encourage use of Derby and expect the
current separation of jars that we have now.  Users should be able to
install  applications that embed future versions of Derby and have
things still work as they do today.  If they don't it's a *regression*.

I was fascinated by David's priority list:  first Product, then User,
then Engineer and think it is really great that we actually seem to have
all permutations of this priority list represented here.   All are
important  and need advocates, but  when you have an installed user
base, sometimes the engineers have to be a little careful and patient.

 Of all the approaches presented thus far, I like.

Approach 3) Wait until we have some new set of  code that  we can use as our first code sharing
test case and untangle the existing code later.

This way the big thinking engineers can have fun and do pretty what they want without the
installed user base getting in the way.


Kathey




Mime
View raw message