Sorry for the misnomer, but the bundles between them self seem to have used It as Api.
And yes we know by heavy experience that mixed versions of Jetty is bad - even at the .z level. We've had the issue in past - it's just that it now repeated and thus we wanted to raise it to know how to handle it.
But there is now way for us to actually control this when jetty itself in its version ranges says .10 when it actually needs .13 and vice Versa.
I.e. Platform required some jetty .9 or upwards at Mars.0, We add a dependency in our plugins to other parts of jetty as .9 and upwards. As long as only .9 is available to Osgi to resolve things are good.
In Mars .1 jetty .13 is bundled. Now when our bundles are resolved it ends up with a mix of .9 and .13 with no dependency resolution errors.
Only at runtime the issue occurs since .9 and .13 are actually *not* compatible with each other.
We monitor this list.
However, the filed bug says "This class was API and was used by several of the other jetty bundles." Which is confusing, as SpinLock is internal, not API. And using mixed versions of Jetty (on the server side) is generally frowned upon (at least from the non-OSGi point of view).
|