How I Came to Hate Orbit

29. February, 2012

Orbit is an Eclipse project which contains IP clean OSS code to be used in Eclipse projects.

Why is that important? Well, IP clean means that big companies who consume Eclipse code, can use it safely (their lawyers have to check the EPL once and after that, their developers can use any code they can find on eclipse.org).

Now, Eclipse writes a lot of source code but not everything. commons-io, for example, contains a lot of code which would be really cool to have for Eclipse projects.

Orbit was created to have just that: Copies of OSS code from all kinds of places relicensed under the EPL. Sweet.

Enter stage: maven.eclipse.org

The idea behind maven.eclipse.org is to provide projects outside of the Eclipse foundation a place where they can find Eclipse’s OSGi bundles as Maven artifacts (which are easier to consume when you build your projects with Maven). Sweet 2.

To make the Eclipse bundles available on maven.eclipse.org, I need to convert them. Part of that process is to assign each Eclipse bundle (which has bundle ID and a version) a Maven coordinate (which consists of group ID, artifact ID and version). That’s not always simple but I’ve found a rule that works pretty well.

If it wasn’t for Orbit.

Orbit contains bundles which you can also find on Maven central. One example is commons-io.

And Orbit didn’t simply copy the JAR from Maven Central – they changed it. In this case, the changes are purely for legal reasons (EPL license, moved a couple of files around). Not a big problem here. I could map the two to the same coordinate – except that you would sometimes build software which contains code licensed by Apache and sometimes code which is licensed by EPL. Worse, some other code might be under the viral GPL on Maven Central – linking that could turn your project into open source! Not a problem for most developers but it could be a problem for your legal department and guess which head is going to roll?

But there is more.

Let’s have a look at … org.apache.batik.pdf. This is a fragment of the Batik’s rasterizer JAR from Maven Central. In this case, we have several issues:

  • Orbit has split a single artifact from Maven Central into several Orbit bundles. Which bundle should get the same coordinate as the original Maven Artifact?
  • The Orbit bundle also contains code from commons-io and commons-logging. So it pollutes your classpath with classes that you don’t expect. Worse, someone (not the Eclipse guys) removed “unnecessary” methods from some classes copied from commons-io. So if the compiler sees this JAR on the classpath, you will get errors for many methods in the class IOUtils. Bad.
  • Some Orbit bundles have bugs fixed but the version hasn’t been changed – only the qualifier changed which works if you use OSGi to build your classpath but Maven doesn’t. A couple of bundles from org.apache.batik are among them (bug 329376).

While it might make sense from Orbit’s point of view to do this, it makes my life a bit complicated.


Maven Tool 4 Eclipse 0.10.0 Released

12. January, 2012

I’ve just release a new version of Maven Tools 4 Eclipse (Changelog). It fixes the two most pressing issues:

  • Bug 367461 - [mt4e] mt4e needs priming.zip
  • Bug 354381 - Error: groovy.lang.MissingPropertyException: No such property: args for class: m4e.ImportTool

Have Fun!


New Release of MT4E

24. August, 2011

Note: This post is now obsolete since there is a newer release.

I just finished a new release of Maven Tools 4 Eclipse. It’s not written in Groovy and supports all the features of the old Python version plus a few new ones.

You can find instructions how to use it on the wiki page.

For now, you need to build the tool from source (which needs 1.4-SNAPSHOT from DecentXML) using Maven. I’m in discussion with the people at Eclipse to get a download link for the binary.

Update: The project page now has a download link.


New Website for Maven Tools For Eclipse (MT4E)

13. July, 2011

My Maven Tools for Eclipse (MT4E) project has now a wiki page: http://wiki.eclipse.org/Maven_Tools_4_Eclipse

And I’ve started to convert the tools from Python to Groovy.

 

 


Eclipse 3.6.2 Artifacts for Maven 2

20. March, 2011
Apache Maven logo.

Image via Wikipedia

Update: The project has its own web site, now.

Two days ago, I told you about Project Dash and my new tools for it. Well, we did run them over the weekend and import a lot of stuff from Eclipse 3.6.2 into a brand new testing Maven 2 repository.

So if you want to use Eclipse bundles in Maven 2 for your own projects (SWT, EMF, even BIRT), have a look and let me know:

  • Did I miss anything?
  • Is anything wrong? Version numbers, names, dependencies, optional dependencies.
  • Any other comments?

Making the world a better place, one line of code at a time! :-)

The tools are here.

New project home page: Maven Tools 4 Eclipse


Follow

Get every new post delivered to your Inbox.

Join 333 other followers