It started very innocently - unsatisfied package javax.servlet_2.6 in a number of plugins. This clearly indicated a problem with the build - for some reason the package javax.servlet was missing or not built properly.
And here comes the first surprise - javax.servlet package is not Eclipse package, it is a 3rd party library. A short glimpse at the dependecies.properties (a file that maps non-Eclipse library to Fedora libraries) and here it its mapping:
javax.servlet_3.0.0.v201112011016.jar=/usr/share/java/tomcat/tomcat-servlet-3.0-api.jar
And there... there is package javax.servlet_3.0 exported!
That's interesting. Quick search for 2.6 version... There is no such version of javax.servlet specification. Something is wrong. How is it possible that half of the Eclipse plugins uses a version of the javax.servlet that does not exists?
The answer was finally found here:
The workaround for that issue was not simple. I could not patch Eclipse to use 3.0 (too many patches), nor downgrade version in tomcat-servlet-3.0-api - because of too many dependencies.
The Servlet 3 specification is a breaking change for implementers, but is binary compatible for client applications. Following the version guidelines the javax.servlet packages should move from version 2.5 -> 2.6
Thankfully, OSGi allows for exporting the same package more than once:
Export-Package: javax.servlet;version="3.0", javax.servlet;version="2.6",
One patch for Tomcat, and one problem in Eclipse Fedora Build solved :-).
The problem that I am trying to highlight is that Eclipse Foundation maintains its own version of libraries in Orbit, and it may surprise users. I do not want to say that renaming 3.0 to 2.6 was unjustified (because it was), but on the other hand, does Eclipse have to maintain its own copies of libraries, which are unusable for the rest of the world?
Maybe it is a good time to start discussion about Orbit removal, and a true, transparent connection to other libraries, where each local modification should be sent to the upstream?
Orbit meets 3 requirements. The 3rd party libs have been vetted for IP, they have been turned into OSGi bundles so they can be used, and they are available from a p2 repo so they can be consumed by PDE builds.
ReplyDeleteThey're not unusable for the rest of the world, as there's nothing to stop anybody from downloading them from an orbit build (and each build has a map file with the full HTTP URL link).
Chris, the jetty issue is due to the fact that they do not adhere to OSGi versioning rules. It's an unfortunate situation but we had to do what we could.
ReplyDeletejavax.servlet package versions for the Servlet 3 specification
https://bugs.eclipse.org/bugs/show_bug.cgi?id=360245
Gunnar announced this change to the cross project list
http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg06798.html
The Orbit repository is a a very useful tool for commmitters by ensuring that we are all consuming the third party libraries in the same format. It also makes life easier for the foundation IP team. The jetty example is a rare exception where we must modify it from the original version. The reality that this will continue to be a problem because not all third party libraries adhere to the tenants of OSGi semantic versioning.
And what if we could upstream the packaging to project owners and get libraries as bundles directly from their creators?
ReplyDeleteIP check does not seem to require a copy of a library kept at eclipse.org - I guess it might be OK to have only references...