Eclipse Labs Project Hosting Announced

Posted by Alex Blewitt on May 14, 2010

Sections

Architecture & Design,

Development,

Enterprise Architecture

Topics

Eclipse ,

Java ,

Modularity

Tags

Google Apps ,

EclipseLabs ,

Google

The Eclipse Foundation yesterday announced the creation of Eclipse Labs, a code-hosting site for open-source projects that want to play in the Eclipse ecosystem but aren't hosted on the Eclipse Foundation hardware.

In conjunction with Google, Eclipse Labs hosts a Google Project Hosting instance at http://www.eclipselabs.org/. The goal is to allow anyone interested in writing Eclipse plug-ins (or OSGi bundles) a common place to host open-source code, rather than being distributed across many code providers. Naturally, the default licence is the EPL, but other open-source licences can be chosen from the project creation; though it's worth noting that the GPL is incompatible with non-GPL plug-in systems – which explains why there aren't any GPL based Eclipse or OGSi bundles.

Future plans include the ability for plug-ins to declare metadata about their update sites, so that they can be included in the recently-announced Eclipse Marketplace (formerly EPIC). Together with the Helios Eclipse Marketplace Client, it should make installing plug-ins developed by the community much easier from a standard install of the Eclipse platform.

Google announced their first project to be hosted on Eclipse Labs – the “Workspace Mechanic”, which aims to provide a way of synchronising settings between multiple Eclipse workspaces. Having been used internally in Google for some time, Robert Konigsberg explains the benefits:

The Workspace Mechanic can be used in both single-user and enterprise modes to take on automating maintenance of all your Eclipse environments.

One of the coolest things we've added is a Preference Recorder which listens to changes to preferences, and then saves them as tasks you can apply to all the other workspaces on your machine.

Another early adopter of Eclipse Labs is Wascana, an out-of-the-box solution for a Windows-based CDT environment with MinGW based gcc all in one package. Due to gcc's licensing as GPL, it cannot be hosted or distributed from eclipse.org. Although most Unix-based operating systems come with gcc already installed, its lack of presence in Windows means that CDT has had more obstacles when running on a Windows environment. Doug Schaefer, the Eclipse CDT project lead and Wascana creator, thinks it will be a game changer:

When I first heard of Eclipse Labs, I was thrilled about the idea. Having a central hosting site where we can gather all the open source projects that skirt the official Eclipse site is a great way to build visibility for these projects and a great way to promote the creation of new ones.

Well, today, Eclipse Labs is a reality. And, as I was one of the beta testers for it, I'm pleased to announce that I have moved the Wascana Eclipse C/C++ IDE for Windows Developers over to it. I really struggled with Wascana over at SourceForge where there's a low signal to noise ratio, but thanks to Eclipse Labs, it should help people find it and realise its place in the Eclipse community.

Thanks to Ian Skerrett and Google for getting Eclipse Labs together. As I mentioned in the blog post I posted when I first heard of it, this is going to be a game changer. I can't wait to see what projects pop up there.

At the current time, Eclipse Labs supports the same version control systems that Google Code does; SVN and Hg. Git support at Google Code was initially ruled out (although many use Google code via git svn). Their analysis highlighted performance concerns over HTTP at the time:

While there were several DVCSs that we could support, our decision to support Mercurial was based on two key reasons. The primary reason was to support our large base of existing Subversion users that want to use a distributed version control system. Second, given that Google Code's infrastructure is built for HTTP-based services, we found that Mercurial had the best protocol and performance characteristics for HTTP support. For more information, see our analysis.

Since that initial analysis, git has acquired the Smart HTTP Protocol, now used by Github and should be rolled out in the near future for Eclipse's Git repositories. This brings the same speed of the Git protocol across an HTTP binding, which should alleviate that specific concern. (Shawn Pearce, who works at Google, is a committer on both the Git and EGit/JGit projects and developed the Smart HTTP Protocol.) However, until Git support is added to the version control systems supported by Google Hosting, this won't be available at Eclipse Labs.

Will you be moving your Eclipse-based or OSGi-based projects over to Eclipse Labs?

• Older >