far Orbit

I am not a biggest fan of Orbit project. I do, however, understand now, that it is needed due to the legal reasons, as it was stated in the comment to my blogpost nearly a year ago:

• The 3rd party libs have been vetted for IP, 
• they have been turned into OSGi bundles so they can be used
• they are available from a p2 repo so they can be consumed by PDE builds

 The biggest fear I have is that Orbit version of projects is isolated. They get OSGi Manifests, sometimes version number that is different from what is in the original, and sometimes even different name.
All those things does not make adoption and updates easy. There is practically no way to build Eclipse with newer version of a particular library and use it for testing.
So here is my proposition - let's contribute OSGi manifests or even entire packaging back to their providers. They don't always know/care about OSGi, but they rarely object such changes.
This will make the process of new version adoption easier, because testing/3rd party products could use newer version of libraries which is not yet present in the Orbit without taking the effort to build it them themselves.
Of course, I'm not demanding everyone to do it right now, but please, give it a thought before submitting a new [version of] Orbit bundle.

We should be removing the border between Eclipse and the rest of world.

Happy bundling!

Fedora Eclipse Build: far Orbit

Today I will dwell on the issue that hit me when I tried to build a recent Eclipse - something pre-M5. Previous builds of Eclipse using eclipse-build were done for M1, so it is easy to imagine what could go wrong.

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 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

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.

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?