David W. Van Couvering wrote:
Well, we're at a bit of a standoff here. What I'm looking for is a nail-in-the-coffin data point that would move us in one direction or the other.
I've been following this discussion with some interest as my background is technical support. In fact, I supported Cloudscape for the first 4 years (from release 1.0 of Cloudscape). My experience is that developers (particularly Java developers) really liked Cloudscape (now Derby) because it was so easy to use and deploy. And, I found historically that one of the most common issues to come up were classpath issues (in particular we got in trouble a few times when we introduced something that caused the order of the jar files to be important). You should note that I'm not, and never have been, a Derby developer, so I don't claim to be an expert on what's correct and best from a development perspective.
I'm a bit concerned because I see a lot of discussion about what is good from a derby development perspective, but not so much how these changes may affect users of Derby. Although some Derby users have complex applications (like application servers), many are implementing much more simple solutions. Having said that, I'm a bit lost in what is being proposed from the user/functional perspective. David, as soon as you have a more concrete proposal (may not be the time yet), can you post that information? Could you provide information on what the users of Derby will have to do with this change (how would our documentation need to be changed) and maybe footprint, performance, etc. impacts vs. the benefits from making this change. I'd like to be able to provide my input from a usability/documentation perspective.
In addition, I work on Derby now in the testing area, so I'd also like to understand the implications for what additional testing might need to be done. If we create more jar files, is there more testing requirements for different combinations?
Thanks, Kathy
