Maven Deploy von Bundles mit Abhängigkeiten an nicht-Bundles

[musiKk]

Hallo,

ein kleiner Auszug aus [c]mvn dependency:tree[/c]:

[INFO] +- com.company:mybundle:jar:1.1.0-SNAPSHOT:compile
[INFO] |  +- org.apache.felix:org.apache.felix.main:jar:3.0.7:compile
[INFO] |  +- org.apache.felix:org.apache.felix.framework:jar:3.0.2:compile
[INFO] |  +- org.apache.felix:org.apache.felix.gogo.command:jar:0.8.0:compile
[INFO] |  |  +- org.apache.felix:org.apache.felix.gogo.runtime:jar:0.8.0:compile
[INFO] |  |  \- org.apache.felix:org.apache.felix.bundlerepository:jar:1.6.0:compile
[INFO] |  |     \- org.easymock:easymock:jar:2.4:compile

Easymock 2.4 ist kein OSGi-Bundle, sondern ein normales JAR. Neuere Versionen wohl schon, aber das kann ich dem Felix Bundlerepository ja schlecht vorschreiben. Wie soll ich jetzt vorgehen, damit das nicht-Bundle zur Laufzeit des OSGi-Containers (in diesem Fall Felix) gefunden werden kann? Ich stehe da etwas auf dem Schlauch.

Das bisherige Vorgehen eines (nicht von mir) selbstgestrickten Build-Tools ist, in allen Abhänigkeiten zu schauen ob es Bundle-Informationen im Manifest gibt. Falls ja fliegt das JAR in ein Bundle-Verzeichnis, ansonsten in ein Lib-Verzeichnis. Letzteres wird beim Start hart in den Classpath eingetragen: [c]java -cp "lib/*.jar" ... org.apache.felix.main.Main[/c]. Das sollte doch auch sauberer gehen, oder?

Gruß
mK

 

[maki]

Vorab: Kenne mich mit Felix nicht aus, nutze von jeher nur Equinox.

Was mich wundert ist, dass jemand ein Mocking Framework zur Laufzeit braucht (egal ob OSGi oder nicht), sollte doch eigentlich nur für Unittests genutzt werden.

 

[musiKk]

Ok, ich habe mich inzwischen nochmal mit den entsprechenden Entwicklern zusammengesetzt und wir haben festgestellt, dass die zur Laufzeit benötigten nicht-OSGi-Abhängigkeiten vom durch Bnd inspirierten [c]maven-bundle-plugin[/c] in die entsprechenden Projekte kopiert werden. Insofern war der ganze Aufriss mit dem Lib-Verzeichnis evtl. überflüssig.

Das mit dem Dependency-Tree wundert mich dennoch. Easymock wird zur Laufzeit allem Anschein nach nicht benötigt. [c]mvn dependency:tree[/c] listet es dennoch. Es wäre nützlich, wenn ich zwischen solchen und zur Laufzeit benötigten unterscheiden könnte.

 

[maki]

Es wäre nützlich, wenn ich zwischen solchen und zur Laufzeit benötigten unterscheiden könnte.

das kann man in maven, nennt sich "scope" und dieser steht hier auf "compile" anstatt auf "test"

org.easymock:easymock:jar:2.4:compile

Warum das entweder nciht richtig gemacht wurde oder EasyMock doch zur Laufzeit gebraucht wird kann ich dir von hier aus leider nicht sagen.

Nebenbei, imho ist es übertrieben für eine Fremdlib ein Maven Projekt welches das Bundle Plugin nutzt zu erstellen, reicht ja wenn es einmal gemacht wird, das geht mit Eclipse schneller:
How to create Eclipse plugins from jars

 

[musiKk]

Nebenbei, imho ist es übertrieben für eine Fremdlib ein Maven Projekt welches das Bundle Plugin nutzt zu erstellen

Ich weiß jetzt nicht, wo die Grenzen zu ziehen sind, aber es ist schon mehr als eine Abhängigkeit. Der Dependency-Tree ist schon um einiges größer als das Fragment aus meinem ersten Post.

Inzwischen sieht es so aus, dass die Bundles die Abhängigkeiten durch das [c]maven-bundle-plugin[/c] automatisch reinkopiert bekommen. Das größte Problem was sich dadurch noch stellt ist, wie ich das ganze deploye. Momentan mache ich einfach ein [c]mvn -DoutputDirectory=mein-bundle-dir dependency:copy-dependencies[/c] und alles ist gut. Dadurch habe ich zwar auch ein paar Bibliotheken doppelt (die verwendeten nicht-OSGi-Libs sind jetzt einmal in den verwendenden Bundles und noch einmal als jar vorhanden - der Abhängigkeitsmechanismus von Maven kann das ja nicht unterscheiden), aber die werden von Felix ignoriert. So richtig glücklich bin ich damit allerdings noch nicht...

Vielleicht ist OBR doch noch einen Blick wert...

 

[maki]

Um eine target Platform zu erstellen nutze ich meist das assembly plugin, wenn man die OSGi Bundles sowieso neu erstellt, kann man auch darauf achten dass nur OSGi Bundles als Dependencies referenziert werden.
wenn man Orbit Bundles nutzt, muss man diese soweiso noch mavenisieren, das Spring Enterprise Repository bietet auch schon sehr viele OSGI-fizierte Libs an, inkl. Maven Konfig.