Plugin-manifest for Eclipse-plattformen

Versjon 3.0 - Sist endret 24. juni, 2004

Dette er en arkivert versjon av dokumentet. Gjeldende versjon finnes her.

Definisjonene for manifestkodetypene nedenfor bruker mange forskjellige navngivningssymboler og IDer. Her er noen produksjonsregler [referert i teksten nedenfor] for å unngå tvetydighet. Generelt skiller alle IDer mellom store og små bokstaver.

SimpleToken := tegnsekvens ('a-z','A-Z','0-9','_')
ComposedToken := SimpleToken | (SimpleToken '.' ComposedToken)
JavaClassName := ComposedToken
PlugInId := ComposedToken
PlugInPrereq := PlugInId | 'export' PlugInId
ExtensionId := SimpleToken
ExtensionPointId := SimpleToken
ExtensionPointReference := ExtensionPointID | (PlugInId '.' ExtensionPointId)

Resten av denne delen beskriver plugin.xml-filstrukturen som er rekke DTD-fragmenter. Filen plugin.dtd presenterer DTD-definisjonen i sin helhet.

<?xml encoding="US-ASCII"?>
<!ELEMENT plugin (requires?, runtime?, extension-point*, extension*)>
<!ATTLIST plugin
  name               CDATA #REQUIRED
  id                 CDATA #REQUIRED
  version             CDATA #REQUIRED 
  provider-name       CDATA #IMPLIED
  class               CDATA #IMPLIED 
>

<plugin>-elementet definerer hoveddelen i manifestet. Det kan inneholde definisjoner for plugin-modulens kjøretid, definisjoner av andre plugin-moduler som denne krever, deklarasjoner av eventuelle nye utvidelsespunkter som blir introdusert av plugin-modulen, i tillegg til konfigurasjon av funksjonsutvidelser (konfigurert i utvidelsespunkter definert av andre plugin-moduler, eller introdusert av denne plugin-modulen). Dette er <plugin>-attributtene:

XML DTD-konstruksjonsregelen element* betyr ingen eller flere forekomster av elementet, element? betyr ingen eller en forekomst av elementet og element+ (brukt nedenfor) betyr en eller flere forekomster av elementet. Basert på <plugin>-definisjonen over betyr dette for eksempel at plugin-modulen bare inneholder en kjøretidsdefinisjon, og at ingen utvidelsespunktdeklarasjoner eller utvidelseskonfigurasjoner er gyldige (for eksempel felles biblioteker som andre plugin-moduler er avhengige av). På samme måte er en plugin-modul som bare inneholder utvidelseskonfigurasjoner og ikke egne kjøretids- eller utvidelsespunkter, også gyldig (for eksempel konfigurering av klasser avledet fra andre plugin-moduler i utvidelsespunkter deklarert i andre plugin-moduler).

Delen <requires> i manifestet deklarerer eventuelle avhengigheter på andre plugin-moduler.

<!ELEMENT requires (import+)>
<!ELEMENT import EMPTY>
<!ATTLIST import
 plugin               CDATA #REQUIRED
 version              CDATA #IMPLIED
  match               (perfect | equivalent | compatible | greaterOrEqual) "compatible"
 export               (true | false) "false"
 optional             (true | false) "false"
>

Hver avhengighet er oppgitt med et <import>-element. Det inneholder følgende attributter:

<runtime>-valget i manifestet inneholder en definisjon av et eller flere biblioteker som utgjør plugin-modulens kjøretid. De refererte bibliotekene blir brukt av mekanismene for plattformutføring (plugin-klasselasteren) for å laste inn og utføre dem riktige koden som plugin-modulen krever.

<!ELEMENT runtime (library+)>
<!ELEMENT library (export*, packages?)>
<!ATTLIST library
  name               CDATA #REQUIRED
  type               (code | resource) "code"
>
<!ELEMENT export EMPTY>
<!ATTLIST export
  name               CDATA #REQUIRED
>
<!ELEMENT packages EMPTY>
<!ATTLIST packages
  prefixes           CDATA #REQUIRED
>

Elementet <runtime> har ingen attributter.

<library>-elementene definerer kollektivt kjøretiden for plugin-moduler. Du må oppgi minst ett <library>. Hvert <library>-element har følgende attributter:

Hvert <library>-element kan oppgi hvilken del av biblioteket som skal eksporteres. Eksportreglene er oppgitt som et sett med eksportmasker. Som standard (ingen oppgitte eksportregler) antas det at biblioteket er privat. Hver eksportmaske er oppgitt med name-attributtet, som kan ha disse verdiene:

Bare plugin-moduler for Eclipse 2.1: Hvert bibliotek kan også oppgi pakkeprefiksene. Disse blir brukt til å forbedre klasseinnlastingsytelsen for plugin-modulen og/eller fragmentet. Hvis <packages>-elementet ikke er oppgitt, er standardverdien at klasseinnlastingsforbedringene ikke blir brukt. Elementet <packages> har følgende attributter:

Plattformarkitekturen er basert på forestillingen om utvidelsespunkter som kan konfigureres. Selve plattformen forhåndsdefinerer et sett med utvidelsespunkter som dekker oppgaven med å utvide plattformen og skrivebordet (for eksempel legge til menyhandlinger, legge til innebygd redigeringsprogram). I tillegg til de forhåndsdefinerte utvidelsespunktene kan hver plugin-modul som leveres, deklarere andre utvidelsespunkter. Ved å deklarere et utvidelsespunkt annonserer utvidelsespunktet i virkeligheten muligheten til å konfigurere plugin-funksjonen med utvidelsespunkter levert eksternt. For eksempel kan plugin-modulen Page Builder deklarere et utvidelsespunkt for å legge til nye DCTer (Design Time Controls) i byggerpaletten. Dette betyr at Page Builder har definert en arkitektur for hva det betyr å være en DTC, og har implementert koden som ser etter DTC-utvidelser som er konfigurert i utvidelsespunktene.

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

Elementet <extension-point> har følgende attributter:

Faktiske utvidelser er konfigurert i utvidelsespunkter (forhåndsdefinert, eller nylig deklarert i denne plugin-modulen) i <extension>-delen. Konfigurasjonsinformasjonen er oppgitt som velformet XML mellom kodene <extension> og </extension>. Denne plattformen oppgir ikke den faktiske formen på konfigurasjonskodetypen (annet enn at det kreves at den er velformet XML). Kodetypen er definert av leverandøren av plugin-modulen som deklarerte utvidelsespunktet. Plattformen tolker ikke konfigurasjonskodetypen. Den bare sender konfigurasjonsinformasjonen til plugin-modulen som del av behandlingen av utvidelsespunktet (samtidig som utvidelsespunktlogikken utfører spørringer i alle de konfigurerte utvidelsene).

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

Elementet <extension> har følgende attributter:

Viktig: Innholdet i <extension>-elementet er deklarert med ANY-regelen. Det betyr at all velformet XML kan oppgis i delen for utvidelseskonfigurasjon (mellom kodene <extension> og </extension>).

Fragmenter blir brukt til å øke omfanget av en plugin-modul. Man kan for eksempel ta med data som meldinger og etiketter i andre språk.

<?xml encoding="US-ASCII"?> 
<!ELEMENT fragment (requires?, runtime?, extension-point*, extension*)>
<!ATTLIST fragment
  name               CDATA #REQUIRED
  id                 CDATA #REQUIRED
  version             CDATA #REQUIRED
  provider-name       CDATA #IMPLIED
  plugin-id           CDATA #REQUIRED
  plugin-version      CDATA #REQUIRED
  match               (perfect | equivalent | compatible | greaterOrEqual) "compatible"
>

Hvert fragment må være knyttet til en bestemt plugin-modul. Den tilknyttede plugin-modulen er identifisert med <plugin-id>, <plugin-version> og eventuelt <match>. Legg merke til at hvis denne spesifikasjonen samsvarer med flere plugin-moduler, blir plugin-modulen med det høyeste versjonsnummeret brukt.

Komponentene <requires>, <runtime>, <extension-point> og <extension> i et fragment blir logisk lagt til den samsvarende plugin-modulen.

Dette er <fragment>-attributtene: