Eclipse Foundationは、昨日 Eclipse Labs をスタートしたことをアナウンスした、オープンソースプロジェクトためのソースコードのホスティング サイトで、 Eclipseエコシステムで遊びたいが、 Eclipse Foundationサイトでホストできないプロジェクトのためである。
Googleと協力して、 Eclipse Labsは、 http://www.eclipselabs.org/に Google Project Hostingインスタンスをホストしている。その目標は、 Eclipseプラグイン（あるいは、 OSGiバンドル）を書くことに興味のある人は、誰でも、いくつものコードプロバイダをまたいで分散されるのではなく、共通の場所でオープンソース コードをホストできるようにすることである。当然、デフォルトのライセンスは、 EPLだが、プロジェクト開始から他のオープンソース ライセンスを選ぶことができる。しかし注意がいるのは、GPL は、非GPLプラグインシステムと非互換である。－なのでGPLベースのEclipse や OGSiバンドルは、ここにはないわけである。
将来計画では、プラグインがアップデート サイトについてのメタデータを宣言できるようになるので、最近アナウンスされた Eclipse Marketplace （以前の EPIC）に含めることができる。 Helios Eclipse Marketplace Client といっしょに、この能力により、 コミュニテによるインストールするプラグインの開発が、Eclipseプラットフォームの標準のインストールからずっと簡単になる。
Googleが Eclipse Labsにホストする最初のプロジェクトをアナウンスした – “Workspace Mechanic”で、複数の Eclipseワークスペース間で設定を同期させる方法を提供するのが狙いである。Google内部である期間、使われており、 Robert Konigsberg氏がその 利点を説明している:
Workspace Mechanicは、シングルユーザ、エンタプライズの両方のモードで使え、あなたのすべての Eclipse環境を自動的に保守してくれる。
我々が追加した最も優れた機能の１つが、Preference Recorder で、プレファレンスの変更を監視して、それらの変更をあなたのマシンの他の全ワークスペースに適応できるタスクとして、保存できる。
Eclipse Labsの別の早期採用者が、Wascanaで、全てが１つのパッケージに入っている、gccベースの MinGWを持った、 WindowsベースのCDT環境対応のすぐに使えるソリューションである。gccのライセンスがGPLのため、eclipse.orgからホストしたり、配布できない。ほとんどの UnixベースのOSには、gccが既にインストールされているが、 Windowsには、ついてこないので、 Windows環境でCDTを走らせるには、ずっと障害があった。Eclipse CDT プロジェクトのリーダで、 Wascanaの作成者である Doug Schaefer氏は、 Eclipse Labs が、ゲームルールを変更することになると考えている:
私が最初、 Eclipse Labsについて聞いたとき、その考えに感動しました。公式の Eclipseサイトを敬遠するオープンソースのプロジェクトを皆集めることができる中央ホスティングサイトを持つことは、これらのプロジェクトが知られるようになる素晴らしい方法であり、新しいプロジェクトを作ることを奨励する素晴らしいやり方でもあります。
今日、 Eclipse Labsが現実になりました。私は、ベータテスタの一人だったので、Windows 開発者のための Wascana Eclipse C/C++ IDEを Eclipse Labsに移したことをアナウンスするのは、非常にうれしいです。雑音が多くてまともな意見の少ない SourceForgeでは、私は本当に、 Wascanaで苦労しましたが、 Eclipse Labsのお陰で、人々がEclipse コミュニテでWascanaに気がつき、どこにあるのかわかるのが、容易になります。
Ian Skerrett 氏とGoogleのお陰で、 Eclipse Labsがまとまりました。ブログ投稿 で言ったように、私が最初に Eclipse Labsのことを聞いたとき、これはゲームルールを変更することになるだろう、と書きました。どんなプロジェクトが出てくるのか、楽しみでしかたありません。
今のところ、 Eclipse Labsは、 Google Codeと同じバージョン コントロール システムをサポートしている； SVN と Hgである。 Google CodeでのGitサポートは、始めから採用されなかった （多くの人が git svn経由でGoogle Codeを使っているが）。彼らの分析は、この時、HTTPでのパフォーマンス上の懸念を強調していた:
我々がサポートできるいくつかのDVCSがあったが、 Mercurialをサポートする決定は、２つの重要な理由に基づいている。１つ目が、分散バージョン コントロール システムを使いたがっている既存の Subversionユーザという大規模なベースをサポートしなければならないこと。２つ目が、 Google CodeのインフラがHTTPベースのサービス向けに作られていることを考えると、Mercurial がHTTPサポートに最高のプロトコルとパフォーマンス特性を有していることがわかった。更なる情報は、我々の分析を見て欲しい。
あの最初の分析以来、git は、Smart HTTP Protocol を実装し、今や Github で使われている。そして近い将来、EclipseのGitリポジトリで大いに使われるべきである。こうなれば、どのHTTPバインディングでもGitプロトコルは、同じスピードになり、前述の特別な心配を多少とも解決することになる（Googleで働く、Shawn Pearce氏は、GitとEGit/JGitの両方のプロジェクトのコミッタで、Smart HTTP Protocolを開発している) 。しかし、Google Hostingによってサポートされているバージョン コントロール システムに、Gitサポートが加わるまで 、Gitは、 Eclipse Labsで、使えない。
あなたは、 Eclipseベース あるいは OSGiベースのプロジェクトを Eclipse Labsに移しますか？