Maven Verwendung von commons-configuration in einem OSGi-Bundle

[musiKk]

Hi,

ich habe wieder ein Problem mit der Erstellung von OSGi-Bundles durch Maven.

Konkret würde ich in einem Bundle gerne commons-configuration verwenden. Dieses ist auch durch entsprechende Manifest-Header von Haus aus "OSGi-fiziert".

Ein Start meines Bundles schlägt jedoch erstmal fehl, weil commons-configuration optionale Maven-Abhängigkeiten an verschiedene Bibliotheken (teilweise keine Bundles) hat, die jedoch alle durch [c]Import-Package[/c] benötigt werden. Beispiel: Es gibt eine optionale Maven-Abhängigkeit an javax.mail:mail:1.4; [c]Import-Package[/c] importiert aber explizit [c]javax.mail.internet[/c] u. v. m.

Ich habe noch einen wahrscheinlich entsprechenden Bug-Report gefunden, um den sich aber seit 1.5 Jahren keiner gekümmert hat.

Wie kann ich diese Diskrepanz zwischen Maven- und OSGi-Abhängigkeiten lösen? Wenn ich alle Abhängigkeiten sowieso brauche, wieso sind sie dann optional? Und wenn ich alle optionalen Abhängigkeiten nochmal extra angeben muss, wozu habe ich dann ein Dependency-Management? Wie soll ich die nicht-Bundles (wie z. B. javax.mail:mail) commons-configuration verfügbar machen?

 

[maki]

Es gibt bei eclipse Orbit OSGi Versionen von javax.mail etc.: Build R20100519200754 - Orbit Download

Ist natürlich keine echte Lösung, sondern nur ein Workaround, was schade ist, ist dass diese (und andere) Abhängigkeiten wohl nur beim Testen genutzt werden...

Nachtrag: das SpringSource Enterprise Repo hat auch welche: SpringSource Enterprise Bundle Repository

 

[musiKk]

Ok. Ich glaube, so wird das nichts. Ich habe jetzt commons-configuration aus dem SpringSource-Repo verwendet (bei Orbit ist es nicht vorhanden). Jetzt schlägt das ganze aufgrund transitiver Abhängigkeiten fehl (commons-jxpath benötigt noch die JSP API, diese benötigt wieder EL, und was weiß ich noch) weil die alle auf [c]provided[/c] gesetzt sind - im Kontext von Spring ist das vielleicht auch sinnvoll, aber ich verwende kein J2EE, sondern nur J2SE.

Dadurch wird das ganze Dependency-Management ja ad absurdum geführt...

 

[maki]

Hast du denn das SpringSource ENterprise Repo als Repository eingetragen? Dann sollte es funzen.
Wenn du nur dir eine jar in dein eigenes Repo hochlädst wird das natürlich nix.

 

[musiKk]

Das Spring-Repo ist schon eingetragen. Die direkte Abhängigkeit [c]org.apache.commons:com.springsource.org.apache.commons.configuration[/c] sowie alle weiteren Abhängigkeiten werden ordentlich aus dem Repo gezogen. Die [c]provided[/c]-Abhängigkeiten werden aber nicht vom Maven Dependency Plugin beachtet:

... snip ...
[INFO] |  +- org.apache.commons:com.springsource.org.apache.commons.jxpath:jar:1.2.0:compile
[INFO] |  |  \- org.jdom:com.springsource.org.jdom:jar:1.0.0:compile
... snap ...

In meinem "Environment" kann ich diese Abhängigkeiten aber nicht als provided betrachten; ich habe kein J2EE laufen.

EDIT: Falls schon wer was gesehen hat: Sorry, ich habe ein paar Falschaussagen etwas abändern müssen.

 

[maki]

Ok, jetzt hab soagr iche s verstanden

Der provided Scope bedeutet, dass die Abhängigkeit vom Laufzeitsystem erfüllt wird, zB. die Servlet API bei Servlet Containern.

Persönlcih bevorzuge ich es, OSGifizierte versionen selber herzustellen mit Eclipse, da hat man mehr Möglichekiten, oder eben vorhandene zu nutzen wenn diese passen.

 

[musiKk]

Nun, wir haben uns dagegen entschieden. Der Aufwand ist einfach zu hoch. Da das Konfigurationsformat auch noch nicht feststand, sind wir auf Java Properties umgestiegen und benötigen somit commons-configuration nicht.

Konzeptionell gesehen ist es natürlich schade. Ich möchte aber so viel Komplexität aus unserem eigenen Build-System heraushalten wie nur möglich. Dort soll mit [c]mvn package[/c] und [c]mvn dependency:copy[/c] eigentlich alles getan sein.

Vielleicht gibt es ja irgendwelche Plugins, die diese ganze Problematik vereinfachen können, aber dazu fehlt eben leider auch die Zeit. Bei einer "wichtigeren" Lib hätte ich mir die vielleicht auch noch genommen; für simple Konfigurationsdateien nicht.