Self-Hosting ist ein Vorgang, bei dem ein Computerprogramm verwendet wird, um neue Versionen des gleichen Programms zu erstellen. Self-Hosting wird häufig bei der Compiler-Entwicklung verwendet, bei der neu Versionen des Compilers in der Zielsprache des Compilers geschrieben werden und vom Compiler selbst als Testabschnitt umgewandelt werden. In Eclipse verweist Self-Hosting auf die Verwendung von Eclipse zum Entwickeln von Eclipse-Plug-ins. Die Verwendung von PDE an sich stellt bereits Self-Hosting dar.
PDE unterstützt zwei Arten des Self-Hosting. Beide haben Vor- und Nachteile und wurden für unterschiedliche Verwendungsszenarios entworfen. Sie unterscheiden sich in der Art, in der Plug-in-Abhängigkeiten verwaltet werden.
Einfaches (Standalone) Self-Hosting verwendet externe Plug-ins zum Auflösen von Plug-in-Verweisen. Es ist einfach, leicht zu verwalten und zu verstehen und ist vollkommen ausreichend für Standalone-Entwickler (d. h. Entwickler, die keine fernen Repositories verwenden, um Ihren Code mit anderen gemeinsam zu benutzen).
Self-Hosting für Binär-Projekt führt einen Schritt ein, mit dem externe Plug-ins als Binär-Projekte in den Arbeitsbereich importiert werden. Diese dürfen ebenfalls nicht modifiziert werden und werden üblicherweise mit einem Binär-Projektfilter in der Sicht "Paket-Explorer" verdeckt.
PDE bietet im Release 2.1 als neue Funktion eine zusätzliche Darstellung, die eine Mischung aus dem Self-Hosting von einfachen und binären Projekten ist. In diesem Modus werden Einträge für abhängige Plug-ins als Klassenpfadcontainer dargestellt, der von JDT bereitgestellt wird. Diese Einträge werden abhängig von der aktuellen Situation in der Plattform dynamisch berechnet. Falls ein Plug-in, auf das verwiesen wird, außerhalb der Plattform (= extern) gefunden wird, wird der Verweis als externe JARs aufgelöst. Werden die Plug-ins im Arbeitsbereich gefunden, wird der Verweis in den Projektverweis aufgelöst. Änderungen am Arbeitsbereich wirken sich sofort auf den Klassenpfad im Container aus. Schließlich führen Änderungen an der Zielplattform nicht zu veralteten und/oder instabilen Klassenpfaden, da die Einträge nur bei Bedarf berechnet (und nicht fest codiert oder gespeichert) werden.