Ein Softwareprojekt besteht innerhalb einer Entwicklungsumgebung grundsätzlich aus einer organisierten Menge von Dateien sowie aus Metainformationen, die der Erfüllung bestimmter Aufgaben dienen (z. B. dem Bauen einer ausführbaren Version im Build-Prozess). Traditionellerweise bestehen C/C++-Projekte aus einer einfachen Liste von Dateien, die in einer bestimmten hierarchischen Ordnung in der IDE abgelegt sind. C/C++-Entwicklungsumgebungen wie Metrowerks CodeWarrior oder Microsoft Visual Studio sind gute Beispiele für einen solchen Ansatz. Da die Eclipse IDE in ihrer Entstehung aber auf die Entwicklung mit Java zugeschnitten wurde, beruht die Eclipse-Projekt-Engine auf anderen Prinzipien.
Im Gegensatz zu C-basierten Sprachen existiert in Java eine enge Bindung zwischen den Java-Klassen und den Quelldateien, die diese Klassen enthalten. Damit der Java-Compiler die Klassendefinitionen finden kann, trägt die Quelldatei typischerweise denselben Namen wie die öffentliche Klasse, die sie enthält. Und was noch wichtiger ist: Java-Klassen müssen in Quelldateien abgelegt werden, die in Dateisystemverzeichnissen existieren, die denselben Namen tragen wie ihre Packages. Der einzige Spielraum, den der javac-Compiler zulässt, ist die Festlegung von Classpath-Anweisungen. Doch die grundsätzliche Beschränkung, Java-Quelldateien in Verzeichnissen zu speichern, die mit ihren Package-Namen übereinstimmen, wird dadurch nicht aufgehoben. Bei der Entwicklung mit Java ist die Organisation des Quellcodes also viel rigider zu handhaben als bei C-basierten Sprachen, bei denen der Ort der Quellcodedateien keine Rolle spielt (alle Sourcen müssen explizit dem Compiler zugeführt werden). Header-Dateien sind entweder relativ zu den Quellcodedateien selbst oder relativ zu gegebenen „Include Paths“. C/C++-Entwickler neigen dazu, ihre Quellcodedateien in einem komplexen Netz von Verzeichnissen abzulegen, dessen Struktur von vielen Faktoren abhängt, darunter Release Engineering, Aufteilung des Projekts in Komponenten, Zusammenarbeit im Team und Entwicklungshistorie.
Wegen der beschriebenen Restriktionen in Java bzgl. der Verzeichnis- und Package-Benennung musste Eclipse als Java IDE keine flexiblen Projektstrukturen unterstützen und zeigte in den frühen Releases im Projekt einfach eine genaue Repräsentation des Projektverzeichnisses auf der Festplatte an. Dieses Verfahren erwies sich allerdings schnell als unzureichend für den Einsatz von Eclipse als allgemeine Toolentwicklungsumgebung. Deshalb wurden über die Jahre viele Features ergänzt, um flexiblere Strukturen in Eclipse-Projekten zu ermöglichen, z. B. Funktionen für die Arbeit mit verknüpften Ressourcen (Linked Resources: Dateien und Ordner, die im Gegensatz zu Embedded Resources außerhalb der Projektlokation abgelegt sind). Aber selbst im jüngsten Release der Eclipse-Plattform (Galileo) ist die Verwaltung der Eclipse Projektdateien problematisch für die Arbeit mit Dateien, die sich außerhalb des Projektverzeichnisses befinden. Im Folgenden werden die größten verbleibenden Beschränkungen beschrieben und gezeigt, wie sie durch die neue e4-Plattform aufgehoben werden sollen.
Virtuelle Projektdateienstruktur
Die zur Verfügung stehenden Grundelemente für Ressourcen in Eclipse erlauben es nicht, beliebig komplexe Dateistrukturen in Projekten anzulegen. Die Limitation besteht darin, dass die einzigen verfügbaren Containerobjekte zur Festlegung einer bestimmten Hierarchie die Ordner und die verknüpften Ressourcenordner sind. Unglücklicherweise benötigen beide einen tatsächlich existierenden Ordner im Dateisystem. Die Frage ist hier, ob ihr Vaterelement im Workspace-Baum dasselbe ist wie das entsprechende Vaterelement im Dateisystem.
Um diese Beschränkung aufzuheben, führt e4 so genannte „Gruppen“ (groups) ein. Eine Gruppe ist ein Container (vom API als normale IFolder-Ressource interpretiert), der keinen Ort im Dateisystem besetzt. Aus diesem Grund können nur verknüpfte Ressourcendateien und -ordner unter einer Gruppe erzeugt werden. Gruppen erscheinen in Ressourcennavigatoren als purpurrote Ordner, um sie von regulären Ordnern abzuheben (Abb. 1). Der Projekt-Explorer in e4 kann nun intelligent mit Gruppen umgehen, sodass z. B. auch Drag-and-Drop-Operationen im Projekt-Explorer auf Gruppen angewandt werden können. Wenn der Anwender eine normale Datei-Ressource per Drag-and-Drop auf eine Gruppe zieht, wird nicht einfach eine Fehlermeldung ausgegeben, sondern automatisch eine verknüpfte Ressource erzeugt, die auf die ursprüngliche Datei zeigt.
