Kepler retrospection - was CBI a net loss?

While I was reading Kepler retrospective notes, I found this statement:

CBI was a net loss for us so far. It was a very large volume of work just to get our build back to its old state. There is benefit for others in the community to make it easier for them to run builds independently. For committers it hasn't delivered value yet.

and started immediately wondering who was the "us", and why it was "a net loss".

Fedora had it's own Eclipse build system, which was 8 x faster than current CBI build (15 minutes vs 2 hours on non-SSD drive). I've spent a lot of time getting Eclipse built with Fedora and switched to CBI before the Foundation did.

All that was (and still is) a cost, but was it really "a loss"?

I find it rather as a first step towards a really necessary move - Eclipse Foundation taking responsibility on development. The build system is first, then maybe we will get vendor-neutral architects or UX designers.

Another point is that once it is possible to easily rebuild Eclipse, we can see even right now internal Eclipse teams appearing here and there, which tend to become really valuable contributors.

Not to mention that after Kim left, it took about a month to get builds running again (at the Eclipse Foundation, we had them running in Fedora). Is it ok to have so much power depending on one person (because that is what happens if you have a large ant-based build)?

I'm sorry but I can't agree with a "net loss". It was a necessary cost. Good for the Eclipse Foundation. Good for the Eclipse.

BTW. I really hope some day UX designers or architects will be hired by Eclipse Foundation.

Is running Eclipse on Raspberry Pi possible?

During the weekend I stumbled upon Bug 406749 Create native launcher and product export option for Raspberry Pi, which prodded me to do the long postponed task of contributing patches that has been used in Fedora to built Eclipse for arm.

My patches provide generic arm bundles. It is a part of the work. According to Fedora documentation, Arm processors exist in two versions -  software and hardware floating points. I guess that Eclipse built on one of them might not work on the other one, and it will be necessary to split each arm fragment in two.

It's also worth to consider if Eclipse on arm without FPU is really something we want - it will be unbelievably slow.

But straight to the point - I tested various amounts of memory assigned to maven for the purpose of Eclipse build - and it started succeeding only if maven was granted 900MB. That eliminates Raspberry Pi forever. Sorry for sad news :-(.

However, if you are interested in building Eclipse on various mobile devices, and you'd like to try out those patches, I'd be happy to hear the results!

And a small poll for the end (results can be found here, but please do the poll first!):


 

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!