The Eclipse Common Build Infrastructure aligns the build setup of Eclipse projects and make building an Eclipse based project trivial for external people.
Take building the Eclipse platform for example. Given that you have Maven, Git and Java installed you get a shell and issue the following commands:
git clone -b R4_2_maintenance --recurse-submodules \ git://git.eclipse.org/gitroot/platform/eclipse.platform.releng.aggregator.git LOCAL_REPO=$(pwd)/localRepo cd eclipse.platform.releng.aggregator mvn -f eclipse-parent/pom.xml clean install -Dmaven.repo.local=$LOCAL_REPO mvn -f maven-cbi-plugin/pom.xml clean install -Dmaven.repo.local=$LOCAL_REPO mvn clean install -Pno-bree-libs -Dmaven.test.skip=true -Dmaven.repo.local=$LOCAL_REPO
and after a few hours you have your own custom build of the Eclipse IDE.
Basically all 😉 the cool Eclipse projects, like EGit, Mylyn, Platform have already migrated. You find the complete list of migrated projects here: Eclipse projects using CBI.
I think it would be great if more projects migrate, as this would help others to created custom flavored builds of Eclipse.
Also we are planning a little “build your own Eclipse IDE” context on EclipseCon 2013, so running the build or migrating a project would be a great practice.
It makes me sad that I’m not considered cool because I favour Buckminster 😛
Oh well, I could live with that but the really bad thing is that CBI does not support Buckminster.
@Eike, of course you are still cool… 🙂 I cannot judge Buckminster as I have never used it, but Tycho builds based on CBI are very simple to setup. For the e4 tools is took me half a day to setup the build.
Don’t worry Eike, EMF, Xtext and Xtend are not cool either. And they won’t become cool in the near future. Seems like the underground kids are all using Buckminster. I always considered it to be cooler not to follow the mainstream.
I still prefer Buckminster 🙂
Once you get acquainted with it, it’s really fast to build your projects, and you don’t get bad surprises headlessly, since it basically mimics and reuse Eclipse IDE infrastructure.
Long Live Bucky 🙂
@Lorenzo, Jan I used to ignore Tycho also as I was very happy that I could manage PDEBuild and wanted to avoid learning a new build system as PDEBuild was really painful to learn. I personally was very surprised how easy Tycho is.
Pingback: Cool Eclipse Kids trink Cola. Cool Eclipse Adults enjoy Coffee … | OpenChrom
Great friend!
What I really love about Buckminster is that it is not actually another build system: it can be seen as an headless version of Eclipse, and indeed it reuses the Eclipse build system. Moreover, it provides means to “materialize” components in the headless workspace, mimicking things you would do in Eclipse (e.g., import projects, run Junit tests…).
This also means that, besides some configuration files (to basically instruct how to import projects and what to build and run) everything works like in Eclipse; you don’t have to restate project dependencies in all your bundles, you won’t experience bad surprises (e.g., it works in Eclipse but it does not build with Maven), you won’t need additional efforts to make things, that are natural in Eclipse, work also with Tycho (as far as I remember there’s no way of running real plain Junit tests, neither to run Junit Plugin tests that require PDE, without manual reimplementation of target platform stuff).
If I run a test from within Eclipse with a launch configuration, I just need to pass that launch configuration to Buckminster and that’s all…
I remember this discussion, http://dev.eclipse.org/mhonarc/lists/tycho-user/msg02159.html … that’s when I made the switch 😉
@Lorenzo not sure about this, Tycho can also be based on a target configuration file. I think this has been enhanced in the last versions of Tycho.
Yes, Tycho builds can be based on target configuration files, but the problems are when you try to run a Junit Plugin test which relies on PDE…
as far as I know the bugs are still open and will never be solved, since (see the discussion at link above) “tycho behaves correctly” it’s PDE which does not behave (!?)… well… but I use PDE… I expect the build system to respect it 🙂
Hi Lorenzo,
You probably speak about this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=343152 . I discovered it a while ago and ended up by thinking that it is actually a good thing. All tests relyong on PDE would rather provide and use a good Target Platform than rely on the Eclipse which is hosting the test.
It’s not only for unit test, but it’s general to PDE. Not using a target-platform to do plugin development leads to not-so portable environment.
This issue is easy to workaround by the way, since PDE provides APIs to deal with target-platforms.
About your concerns about Tycho strictness, in the end, it’s better for the project. We can see Eclipse PDE has several places where it “magically” gets things to work. But “magic” is not a good thing in development. Tycho has allowed less magic, and that forces project to conform to the OSGi principles and so on. I really think it helps to make the project less “hacky” and more portable.
I won’t say anything technical against Buckminster since I never tried it, and I assume that having so many important projects using it with enthusiasm shows it’s a good technology too.
However, Buckminster is not a Java technology, it’s an Eclipse one. It’s unknown to the other pieces of Java world and it’s known and used by a minority of Eclipse developers. That’s why I think Tycho has a big advantage: by using more “standard” Java technologies (Maven + OSGi) and then it makes the project using it way more open to contributions since it is a lower entry barrier for new contributors compared to Buckminster.
Lorenzo, what exactly do you mean a “Junit Plugin test which relies on PDE” ? I’ve read the thread you linked of the Tycho user mailing list, but I still didn’t quite get understand it…
What exactly do you rely on with PDE? Do your tests have a hard, source dependency (aka, compile time dependency) on some PDE plugins? Or do you rely on some configuration behavior that PDE runtime effects? If so, what exactly? It seems like a very strange setup to me…
Micheal, if I run a plugin test, with a run configuration based on features (of my target platform – I always use target platforms), that test will mimic Eclipse behavior of the user, and that’s what I want to test; and I test it the same way in my Eclipse IDE, and headlessly, out of the box (with Buckminster)… I may agree that PDE has some hacky behaviors, but I’m interested in PDE afterall 😉 after ages of Makefiles hell, Eclipse build system looks like heaven… Tycho takes me back to Makefiles 😉 but we should probably continue this discussion outside Lars’ blog 🙂
Bruno, I mean a Plugin Test that runs a wizard (contributed by your bundles) that creates in the workspace a plugin project and checks that it builds without errors, for instance.