Bug 477389

Description Rob Stryker 2015-09-14 13:42:34 EDT

On 2015-06-08 11:15:54,  SpinLock.java was removed.  This class was API and was used by several of the other jetty bundles.  This commit was also pushed to the Jetty 9.2.12 branch.

You will note that removal of a class that is API without bumping minor versions is unacceptable according to most API and Versioning strategies. Removing API classes or methods is pretty much unacceptable in a maintenance release. 

I understand why this was done:  you already had a 9.3 branch which had already passed RC1. You obviously felt you could not bump 9.2.12 to become 9.3, because it'd conflict with your 9.3 branch which was coming up for GA. 

The proper solution in this situation is to simply not remove the class. You leave the class and mark it deprecated and delete it in master only. You do not delete the class from maintenance because it will break API. Furthermore, you make sure that all who need the new API from jetty-util 9.2.13 set that version in the import package section of the manifest.mf. 



This bug has actual tangible errors for adopter products. 

Our recent build of our toolset runs in an environment where one of our upstream dependencies (webtools/servertools) requires SOME jetty 9.2.13 bundles. Our own environment also pulls in ALL of jetty 9.2.10. 

All of our bundles have a required version-range on jetty bundles of [9.2.10, 9.3)., because it is assumed there will be no api breakages in such a range. 


After downloading  org.eclipse.jetty.http_9.2.10.v20150310.jar and inspecting the manifest.mf, I see the following:

Import-Package: org.eclipse.jetty.util;version="[9.2,10)",org.eclipse.
 jetty.util.log;version="[9.2,10)",org.eclipse.jetty.util.resource;ver
 sion="[9.2,10)"

It is clear that, in an environment with multiple jetty versions, a org.eclipse.jetty.http 9.2.10 bundle will allow the framework to resolve org.eclipse.jetty.util 9.2.13 as a dependency. The missing class then causes critical errors.