On 10/24/06, Henri Yandell <[EMAIL PROTECTED]> wrote:
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).
<snip/>
OSGi does more in that you can specify import and export package
version ranges for your bundles (rather than fixating on one version),
which at times lessens the headache. But when push comes to shove, the
resolver which forms the basis of the class loading architecture has a
constraint solving algorithm designed to pick the "higher" version
(all else being equal). Its possible for a bundle to fail loading if
fragments require mutually exclusive version ranges of the same
dependency.
Generifying [collections] is a pervasive change for the component,
lets not be shy about package renaming in such cases, especially the
"broad shallow heavily depended on" category.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
