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
