On 10/23/06, Tyler Ward <[EMAIL PROTECTED]> wrote:
I think a very significant part of this problem is just the profusion of jars anyway. The real incompatibility you're worried about is when two projects are using different versions of subcomponents, or at least the multitude of subcomponents makes it that much more likely. Commons isn't that large, it doesn't have lots of outside dependencies, why not just pare it down to one (1) jar, and then the vast majority of this version trouble goes away. Mix and match is a recipe for instability anyway.
Our worry is over the projects using us, rather than the stuff we use. So if a company has a project A, that uses Commons X and OpenSourceProject O, and O also uses X, then project A is going to be stuck on upgrading to X.2 until O also upgrade to X.2. If we rename packages then A can run X.2 and O, with X.1 sitting there for O to use behind the scenes. The package contains the specification version. It's a lame solution though - but smarter stuff would involve much more JVM involvement (OSGi does some of this though I think, but as far as I understand it means users have to have embraced OSGi).
Something like this. Any project can do whatever it wants. Periodically, all projects are collected together, and a single commons jar is produced. When this found to be stable, it becomes the current version. Rinse, repeat. Programs would then be strongly advised to depend on exactly 1 version of commons, etc.... Maybe break into 2 or 3 jars, but this whole 30 jars idea is really where the problem lies, it seems to me. Anything running in the same JVM should use the same version anyway.
I think users would balk at depending on a huge Commons jar - tempting as it would be to merge a few of the central non-dependency ones into Commons JDK. I think it'd also slow down development. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
