Unter http://springosgi.googlepages.com/ befindet sich ein hervorragendes Tutorial zu Spring-DM, welches nebenbei auch die Verwendung der Plugin-Development-Unterstützung von Eclipse erklärt. Wer einmal deren Vorzüge genossen hat, wird wahrscheinlich nie mehr Manifest-Dateien per Texteditor bearbeiten wollen. Außerdem ist es bei der Entwicklung angenehmer, entwickelte Bundles über einen einzigen Knopfdruck im Eclipse zu starten, anstatt sie z.B. über Maven zu bauen und den Container extern zu starten.

Trotzdem kann es wichtig sein, dass die Bundles unabhängig von Eclipse in Maven gebaut werden können, z.B. um komplette Releases mit Tokenersetzung für verschiedene Umgebungen zu bauen. Für Maven2 existiert das Felix Bundle Plugin (http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html), welches fertige Bundles generieren kann.

Da sich die Verszeichnisstrukturen des Eclipse-Plugin-Development-Tools und eines Standard-Maven2-Projektes sehr unterscheiden, wird hier ein Weg beschrieben, wie beide Welten vereinigt werden können.

Als Verzeichnisstruktur des Maven-Projektes wird folgendes vorausgesetzt:

- src

- main

- bundle

- META-INF

- Manifest.MF

- java

Innerhalb von Eclipse muss aber das META-INF-Verzeichnis im Wurzelverzeichnis des Projektes liegen, damit es als Bundle gebaut wird. Deshalb legen wir das Plugin-Projekt innerhalb des Bundle-Ordners an und importieren alle benötigten Resourcen (in diesem Fall nur den java-Ordner) über Verlinkung in das Projekt. Dafür erstellt man einen neuen Ordner und selektiert unter Advanced die Checkbox Link to Folder in file system. Dann wählt man den Java-Ordner und fügt ihn zum Projekt hinzu. Über das Kontext-Menü -> Build Path -> Use as source folder kann dieser Ordner  als Quellordner markiert werden.

Die Verzeichnisstruktur im Eclipse-Projekt sieht jetzt folgendermaßen aus:

- META-INF

- Manifest.MF

- java (Verlinkt)

Jetzt muss nur noch das Maven-Plugin so eingerichtet werden, daß es die Bundle-Konfiguration aus der vom Eclipse erzeugten Manifest-Datei übernimmt. Das kann z.B. so aussehen:

<plugin>

<groupId>org.apache.felix</groupId>

<artifactId>maven-bundle-plugin</artifactId>

<extensions>true</extensions>

<executions>

<execution>

<id>bundle</id>

<phase>package</phase>

<goals>

<goal>bundle</goal>

<goal>install</goal>

</goals>

</execution>

</executions>

<configuration>

<instructions>

<_failok>true</_failok>

<_include>src/main/bundle/META-INF/MANIFEST.MF</_include>

<Include-Resource>{maven-resources},META-INF/spring=src/main/bundle/META-INF/spring</Include-Resource>

</instructions>

</configuration>

</plugin>

Das _include -Tag bewirkt, dass für die Bundle-Generierung die von Eclipse erzeugte Manifest-Datei verwendet wird. Leider wird in Dieser der Klassenpfad Einträge enthalten, die im erzeugten Bundle nicht mehr vorhanden sind, z.B. der bin-Ordner, in welchem die kompilierten Klassen liegen. Das Bundle-Plugin bricht an dieser Stelle ab, obwohl ungültige Klassenpfad-Einträge in Equinox nicht zu Fehlern führen. Der einfachste Weg, dieses Problem zu umgehen, ist _failok auf true zu setzen. Eleganter wäre es, den Klassenpfad-Eintrag vorher zu manipulieren. Wichtig ist nur, dass der Klassenpfad-Eintrag ./ existiert, weil das Bundle-Plugin alle Klassen im Wurzel-Verzeichnis des Bundles ablegt.

Allerdings kann nicht davon ausgegangen werden, dass sich das Bundle auf Anhieb in einem extern gestarteten equinox genauso verhält, wie in Eclipse, da Eclipse zahlreiche Umgebungsvariablen setzt, die von den Default-Werten abweichen. Sollten also ClassNotFoundExceptions bei Klassen auftreten, welche normalerweise zur JRE gehören (z.B. org.w3c.dom.Node) und innerhalb von Eclipse nicht als Dependency eingebunden werden müssen, dann lohnt sich ein Blick in die System-Properties.

Properties prop = System.getProperties();
for (Object k : prop.keySet()) {
System.out.println(k + ” – ” + prop.getProperty(k.toString()));
}

Gibt alle Properties aus. Eine Beschreibung der einzelnen Parameter befindet sich hier

Wichtig sind vor allem die Parameter osgi.compatibility.bootdelegation und org.osgi.framework.system.packages.