最初の記事(source)は、初期のPerlルーツからバージョン4として知られる現在のJava バージョンまでに及ぶeBayのプレゼンテーション層のアーキテクチャーの進化を説明したものである。
「V4アーキテクチャーは、バックエンドのタイプされたJavaオブジェクトを使用してフロントエンドで使用されるすべてのものを表現するというアプローチをとった。ページは、画像を使用しているか?それなら、その画像にJavaオブジェクトがある。その画像を削除する場合、他のJavaクラスを削除するのと同じ位、単純か複雑である。同様のことが、CSSおよびJavaScriptのリンクにも言える。V4は、サーブレットまたはJSPを使用せずにHTMLを作成する。代わりに、実際のHTML DOMがJava言語で表され、サーバ上にCSS およびJavaScriptをつなげることができる。数ある中で最大の問題は何か?コンテンツ?V4のコンテンツシステムは、独特で力強い。独自のXMLベースの言語を使用して、コンテンツコントラクトを作成する。ワードコントラクトの選択は意図的である。コントラクトは、コンテンツの一部(ユニット)の作成に必要なデータの種類を定義する。たとえば、特定のユニットが整数および英語のストリング (例「Raymond has 4 cars」)を必要としているが、2つの整数とそれ以外の言語のストリングを必要としている。種類や基数について複数のバリエーションがある場合もある。コントラクトは、このすべてをXMLで定義する。それからコントラクトは、特定のアプリケーション/ページ/コンポーネントによってサポートされる各言語で実装される。もちろん、Javaでタイプされたオブジェクトとして表される必要があり、使用される目的で提供されることになるすべての動的データ (上記でいう「Raymond」および「4」など)を要求する。関与しているのはすべてタイプされたJavaオブジェクトであるため、コンパイル時にすべて実行される。アプリケーションデベロッパがJavaコードで2つのパラメーターを指定しない場合、コードはコンパイルしない」。
その記事は、アプリケーションを構成する、さまざまな言語によるJava表現をeBayがどのように実装するかを説明するまでに及ぶ。JavaScriptはネイティブコードとして保持され、 Javaでプロキシされ、CSSファイルは開始点として使用されるが、ランタイム時にCSSを生成するために使用されるJavaクラスファイルに取って代わる。コンテンツコントラクトXMLもJavaなどに変換される。eBayのアプローチを貫く中心的なテーマは、Eclipseコードジェネレーターを使 用して、 この変換をすることで単調でつらい仕事から抜け出すということである。eBayはEclipseプラグインを開発して、それぞれのソースファイル(JavaScript、CSS およびXML)をJava表現に変換し、またカスタムエディターを開発し、 専有XMLフォーマットで動作するようにした。最初の記事は、V4コンポーネントのeBayの実行インスタンスをイントロスペクトする例およびそのコンポーネントを直接Eclipseで開く例を示し、終了している。
2番目の記事(source)は、eBayがXMLファイル形式とその他の専有プラグインの組み合わせを使用して、プロジェクトの依存関係を管理する方法について説明して いる。XMLファイルは、 Eclipseが必要なプロジェクトおよび.classpathファイルを生成することを可能にする。 また、XMLコントラクトと同様に、2番目のプラグインがエディタにXMLを提供する。
一連の独自の専有Eclipseプラグインと同様に、eBayも第三者のものを使用している。ソースコード制御用のRational ClearCaseプラグインおよび静的コード分析ツールであるFindBugsが言及されている2つで、eBayによりソースコード承認の一部として使用されている。
ここでの重要な局面は、Eclipseプラットフォームのオープンソースとしての資質である。ソースが公開されて以来、eBayにとって専有プラグインを残りのIDEと統合することが比較的容易な作業になっている。