Plug-in-Manifest der Eclipse-Plattform

Version 3.2 - Letzte Überarbeitung: 9. Mai 2006

Die unten dargestellten Befehlsdefinitionen in der Manifestdatei verwenden unterschiedliche Benennungs-Token und Kennungen. Um eine Mehrdeutigkeit zu vermeiden, hier einige Erstellungsregeln [auf die im Text verwiesen wird]. Im Allgemeinen wird bei allen Kennungen die Groß-/Kleinschreibung beachtet.

SimpleToken := Zeichenfolge aus ('a-z','A-Z','0-9','_')
ComposedToken := SimpleToken | (SimpleToken '.' ComposedToken)
QualifiedId := ComposedToken '.' SimpleToken
ExtensionId := SimpleToken | QualifiedId
ExtensionPointId := SimpleToken | QualifiedId
ExtensionPointReference := SimpleToken | QualifiedId

Der Rest dieses Abschnitts beschreibt die Struktur der Datei "plugin.xml" als Folge von DTD-Fragmenten. Die Datei plugin.dtd stellt die DTD-Definition in ihrer Gesamtheit dar.

<?xml encoding="US-ASCII"?>
<?eclipse version="3.2"?>
<!ELEMENT plugin (extension-point*, extension*)>

Das Element <plugin> definiert den Hauptteil des Manifests. Es enthält optionale Deklarationen von neuen Erweiterungspunkten, die durch das Plug-in eingeführt werden, sowie die Konfiguration von Funktionserweiterungen (die an Erweiterungspunkten konfiguriert werden, die entweder durch andere Plug-ins definiert sind oder durch dieses Plug-in eingeführt werden).

Die XML-DTD-Konstruktionsregel element* bedeutet, dass Null oder mehr Vorkommen des Elements vorhanden sind; element? bedeutet, dass 0 oder 1 Vorkommen des Elements vorhanden sind; und element+ (im Folgenden verwendet) bedeutet, dass eines oder mehrere Vorkommen des Elements vorhanden sind. Ausgehend von der oben beschriebenen Definition in <plugin> bedeutet dies beispielsweise, dass ein Plug-in, das keine Erweiterungspunktdeklarationen oder Erweiterungskonfigurationen enthält, gültig ist (z. B. allgemeine Bibliotheken, von denen andere Plug-ins abhängig sind). Ähnlich ist auch ein Plug-in gültig, das nur Erweiterungskonfigurationen und keine Erweiterungspunkte für sich selbst enthält (z. B. Klassen konfiguriert, die in anderen Plug-ins für Erweiterungspunkte bereitgestellt werden, die in anderen Plug-ins definiert sind).

Die Eclipse-Architektur basiert auf dem Konzept von konfigurierbaren Erweiterungspunkten. Die Plattform selbst gibt eine Reihe von Erweiterungspunkten vor, mit denen die Plattform und der Desktop erweitert werden können (beispielsweise durch das Hinzufügen von Menüaktionen oder das Ergänzen eines integrierten Editors). Neben den vordefinierten Erweiterungspunkten können alle bereitgestellten Plug-ins zusätzliche Erweiterungspunkte deklarieren. Durch das Deklarieren eines Erweiterungspunkts kündigt das Plug-in im Wesentlichen die Möglichkeit an, dass die Plug-in-Funktion mit extern bereitgestellten Erweiterungen konfiguriert werden kann. Das Plug-in für das Seitenerstellungsprogramm könnte beispielsweise einen Erweiterungspunkt für das Hinzufügen neuer DTC-Elemente (Design Time Controls - Steuerelemente für Entwicklungszeit) zur Palette seines Erstellungsprogramms hinzufügen. Dies bedeutet, dass das Seitenerstellungsprogramm eine Architektur für die Bedeutung eines DTC-Elements definiert und den Code implementiert hat, der nach DTC-Erweiterungen sucht, die an den Erweiterungspunkten konfiguriert wurden.

<!ELEMENT extension-point EMPTY>  
<!ATTLIST extension-point 
  name                CDATA #REQUIRED 
  id                  CDATA #REQUIRED    
  schema              CDATA #IMPLIED 
>

Das Element <extension-point> hat die folgenden Attribute:

Tatsächliche Erweiterungen werden an (vordefinierten oder in diesem Plug-in neu deklarierten) Erweiterungspunkten im Abschnitt <extension> konfiguriert. Die Konfigurationsdaten werden in einem gültigen XML-Format zwischen den Tags <extension> und </extension> angegeben. Die Plattform gibt das tatsächliche Format der Konfigurationsbefehle (das über das XML-Format hinausgeht) nicht an. Die Befehle werden durch den Hersteller des Plug-ins definiert, das den Erweiterungspunkt deklariert hat. Die Konfigurationsdaten werden von der Plattform nicht im eigentlichen Sinn interpretiert. Die Plattform übergibt lediglich die Konfigurationsdaten an die Plug-ins im Rahmen der Verarbeitung für den Erweiterungspunkt (wenn die Logik des Erweiterungspunkts alle konfigurierten Erweiterungen abfragt).

<!ELEMENT extension ANY> 
<!ATTLIST extension 
  point               CDATA #REQUIRED 
  id                  CDATA #IMPLIED 
  name                CDATA #IMPLIED 
>

Das Element <Erweiterung> hat die folgenden Attribute:

Wichtiger Hinweis: Der Inhalt des Elements <extension> wird mit der Regel ANY deklariert. Dies hat zur Folge, dass jede korrekt formatierte XML im Abschnitt der Erweiterungskonfiguration angegeben werden kann (zwischen den Tags <extension> und </extension>).

Fragmente

Fragmente werden verwendet, um den Geltungsbereich eines Plug-ins zu erweitern. Ein Beispiel wäre die Einbeziehung von Daten wie Nachrichten oder Bezeichnungen in einer anderen Sprache.

<?xml encoding="US-ASCII"?> 
<?eclipse version="3.2"?>
<!ELEMENT fragment (extension-point*, extension*)>

Die Komponenten <extension-point> und <extension> eines Fragments werden logisch zum einschließenden Plug-in hinzugefügt.

Hinweis zu "ExtensionId" und "ExtensionPointId"

Es wurde eine spezielle Verarbeitung hinzugefügt, um die Abwärtskompatibilität für "ExtensionId" und "ExtensionPointId", die vor Version 3.2 Punkte (.) enthielten, zu unterstützen. Dabei ergibt sich abhängig von der im Tag <?eclipse version?> angegebenen Version Folgendes:

Diese Regel gilt nur bei Elementen "ExtensionId" und "ExtensionPointId", die Punkte (.) enthalten.


Ältere Versionen des Plug-in-Manifests finden Sie hier: