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.

Leave a Comment » | Software | Tagged: , , , , , | Permalink
Posted by digulla

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!

1 Comment | Software | Tagged: , , , , | Permalink
Posted by digulla

Using Maven to Patch Third Party Code

26. October, 2011

If you have the source for the dependency, patching the code is simple: Just create a small Maven project that compiles the source with your changes. Since your changes are probably small, you need only a few tests: What’s the point to test the code that you didn’t touch? Also the build will be simple (just compile the sources for your need, no fancy resource processing/filtering).

But what if you don’t have the sources? Jakub Holý has a solution: Hacking A Maven Dependency with Javassist to Fix It

Leave a Comment » | Software | Tagged: , , , | Permalink
Posted by digulla

Push Button Builds

8. September, 2011

A few days ago, kingargyle posted about “Push Button Builds.” The idea is that building a software should be as simple as triggering a light switch.

A good example are Maven (mvn install) or most automake builds (configure && make && make install). They usually just work and if they fail, they give you some context to work from.

A good negative example are Eclipse PDE builds: Often there is no build script. If there is a build script, it will fail with an obscure error message in an Ant script that was recursively called by about 100 other Ant scripts. Each Eclipse project uses PDE but each build has different prerequisites (which you must know). If the build uses p2 repositories, there is no way of telling whether two subsequent builds will produce the same result. Some projects try really hard to help newcomers to build their stuff with a recipe that needs 100+ easy steps. In four words: It’s a mess.

Or a surefire way to attract only the most dedicated committers because everyone else will be utterly demotivated very quickly (and you don’t want those, do you? 😉

So like Dave Carver, I would like to spread the idea. Make builds more simple. Here is an example and following Dave’s advice, I’m going to make the build script even more simple.

Why a script and not, say, a web site with instructions? Several reasons:

  1. A script will make you more dedicated. It’s easy to be sloppy with a README. With a script, at least the syntax will be right.
  2. When a README fails, you won’t really know what to do next. With a script, you have a very precise starting point for a bug report: “The setup script failed in line 15” vs. “Install with Maven … and which version?”
  3. Scripts can prepare the environment. Since you don’t want to make anyone angry, create a new directory and put everything in there. Download what you need, unpack it, configure it. If you can’t do it with a script, why should a newcomer fare better?
  4. Can’t download something? You can always print an error message with exact instructions: Go to website … download xxx, version yyy … put it here. In a script, you can say ‘echo “Put download into $build_dir”‘ Try that in a README.
  5. You can prove that a script works. Good luck trying that with a README.
  6. You can run scripts on a CI server to make sure they work.
  7. A script always needs an interpreter. Bash scripts run on Mac and Linux. What about Windows users? Well, 100% of the Windows users build OSS software from .msi files. The tiny rest has three options: a) Read the bash script, b) install Cygwin/MinGW, c) install Linux.

Leave a Comment » | Software | Tagged: , , , | Permalink
Posted by digulla

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.

9 Comments | Software | Tagged: , , , , | Permalink
Posted by digulla

When Maven Crashes Eclipse

8. August, 2011

If your Eclipse IDE suddenly crashes with an error in java.util.zip.ZipFile.getEntry() chances are that you’re hit by this bug: Crash in ZipEntry when some other process changes the ZIP File at the same time

Workarounds:

  1. Close Eclipse when you build your projects with Maven from the command line
  2. Disable automatic refresh (Preferences -> General -> Workspace -> Refresh using native hooks or polling)

 

1 Comment | Software | Tagged: , , | Permalink
Posted by digulla

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.

 

 

Leave a Comment » | Software | Tagged: , , , , | Permalink
Posted by digulla

RC1 of Testing Ready For Testing [Updated]

15. May, 2011

I’ve recreated the testing repository using the latest version of my Maven Tools 4 Eclipse.

To browse the repository, please use the Nexus interface.

If you pull in any dependencies from the repository, non-Eclipse artifacts will come from from Project Orbit. If you want non-Eclipse dependencies (like log4j) from Maven Central, you need to change your profiles.

Deactivate “m4e.orbit” and activate “m4e.maven-central“. From the command line, that’s “-P m4e.maven-central” but I suggest to put these into your settings.xml (add “<activeProfile>m4e.maven-central</activeProfile>” to it).

Note that you don’t need to deactivate the profile m4e.orbit. As soon as you specify a profile on the command line or via the settings, it’s deactivated automatically.

“mvn help:active-profiles” and “mvn dependency:tree” are your friends.

Let me know if you find anything missing, odd, broken by  filing a bug or posting a comment here.

UPDATE 2011-05-30

Some dependencies from the new repo can also be found on Maven Central. One nasty problem is that both repos contain org.eclipse.equinox.app but the version from Maven Central contains odd dependencies which break your build.

To fix this, add this to your parent/root POM:

  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.eclipse.dash</groupId>
        <artifactId>dependency-management</artifactId>
        <version>3.6.2</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    <dependencies>
  <dependencyManagement>

This will limit all version ranges to the versions found in our new repository. Since Maven Central didn’t import new versions for at least one year, this should fix all problems.

Related posts:

Leave a Comment » | Software | Tagged: , , , , , | Permalink
Posted by digulla

Maven Tools for Eclipse: M2 Repository Analysis And Dependency Management

13. May, 2011

I’ve finished RC1 of my set of tools to import Eclipse plug-ins into Maven 2 repositories. You can find the source on github. It needs Python 2.7 and lxml. pip is your friend.

The new features: There is now a tool to analyze the M2 repository for oddities. Currently, it can find these issues:

  • Dependencies which are used but not part of the repository
  • Dependencies which are used with different versions or version ranges (i.e. when one POM includes a dependency with 1.0 and another POM pulls in the very same dependency with version 1.1)
  • Dependencies which are used without versions or version ranges or a catch-all version like [0,)
  • Several versions of the same artifact in the repository

Plus it prints a list of all POMs in the repo with files (jar, pom, sources, test-sources, …). Here is a sample report.

The last tool can create a POM file with a dependencyManagement element containing the versions of the POMs in the repository. You can use this to nail down all versions to the ones existing in your repository (so you don’t accidentally pull in something you don’t want).

Lastly, I’ve enhanced the patch tool. Instead of overwriting replaced dependencies, it will now move them into a new profile. This way, users of the repository can specify which dependency they want (the one from the repository or, say, one from Maven Central).

I will try to build a new testing repo over the weekend so we can start wrapping up the necessary patches for a release.

Related posts: Eclipse 3.6.2 Artifacts for Maven 2

2 Comments | Software | Tagged: , , , , , | Permalink
Posted by digulla

Maven Tools for Eclipse: Patching POMs

11. April, 2011

I’ve added a new feature to my Maven tools for Eclipse: Applying patches to POMs.

This is a first step towards solving issues like this one: Bug 342046 – Invalid third party dependencies in Mavenized BIRT plugins

I’m not 100% happy with the result, though. Currently, the patch overwrites the original code. I think it would be much better if it created a profile instead. This way, you could see the original code and it would be simple to switch between different solutions for a problem in a POM.

The two standard problems are:

  • Bad version (no version, version range or wrong version)
  • Dependency name

The latter is introduced by the fact that Eclipse projects need to pull dependencies via Project Orbit. Orbit often renames dependencies so there is a naming conflict if you pull your dependencies from Maven Central. So we need a way to say “I’m using Orbit” and “I want Maven Central”.

1 Comment | Software | Tagged: , , , , , | Permalink
Posted by digulla

« Previous Entries
%d bloggers like this: