Tuesday, July 17, 2012

Should Maven be enforced by Eclipse Foundation?

I think I can safely assume that you are all accustomed to the idea of Eclipse Long Term Support and it's side product, which is Common Build Initiative. If I'm wrong, then you'd better start reading those wikis ;-).

The basic idea is to let anyone to build any project (including platform) by invoking a very simple command:
mvn clean install
No need to look for any dependencies. No need to check for any version. Just checkout the source and run this command.

Beautiful idea, but easier said than done.

The biggest obstacle is that some Eclipse projects were created a long time before Maven was, and customized their builds to the every possible limit. Some of them rely on the manual builds invocation, and store pre-compiled code in the repo (not only the native one, but also precompiled classes, which, as you already know from this blog, is a big problem for Fedora packagers).

So it is time to choose: should we preserve the pdebuild compatibility, which means that:
  • CBI is monolithic. You build entire platform or nothing.
  • CBI is not usable for building a single project.
  • Either maven-ant-run plugin is used to bridge PDEBuild and Maven, or the build has to be maintained in two places.
Or maybe we should do it right by restructuring all projects to support maven, which means:
  • Some work for projects that use customBuildCallbacks.
  • Forget about the PDEBuild
  • Easy projects builds.
The discussion is already happening @cbi-dev. Be there!


  1. Absolutely not. It is wrong to mandate a particular technology. The right approach is to set down expectations about documentation and ease of running the build. For instance, Sapphire project's build is invoked simply as "ant clean-start". As simple as that Maven command in your post, but that build does a lot more than Maven can out of the box. Why should I invest time re-implementing functionality that already works using a different technology? I see no sense in that.

  2. Enforce isn't quite the right word. Encourage is probably a better one. Eclipse projects will continue to be able to choose the build technology that makes the most sense for them.

    Over time, however, it will become more and more palatable for projects to use Maven/Tycho because life will be easier for them. We are trying to enhance the services we provide for projects around build. To do so in any convincing way requires that we focus our efforts on a small number of technologies, and Maven/Tycho came out as the winner.

    To participate in the Long Term Support (LTS) initiative, a project needs to use the CBI based on Maven and Tycho. This is done because it would be impossible to support multiple different build technologies for the time periods required for long term support.

  3. I can see Maven/Tycho making life easier for new projects with simple build requirements. Not sure about making life easier for existing projects... Nothing is easier than a working build system that you already have. From what I've seen, using Maven/Tycho for simple builds is simple. For anything outside of simple...

    It seems to me that LTS is shooting itself in the foot by insisting on a particular build technology rather than ease of use and documentation. I don't see the bulk of existing projects with existing build systems migrating their build. What's the value proposition?

  4. Konstantin,

    The platform plugins have already made the move. Personnally, I moved EEF builds to tycho over a year ago and helped Acceleo, ATL, EMF Compare to do the same.

    Before tycho, I wasn't able to build correctly EEF, so for me this was easier to make the switch than stay with PDE.