OSGi Implementierung - Fehler bei Import Package

[Zitzit]

Hallo,
ich arbeite derzeit an einer integration von Drools in SMILA via OSGi. SMILA stellt eine Target Platform bereit in dessen Plugin Ordner ich die Drools Bundles (insb. API und Core) herein kopiert habe. Auf diese habe ich in Eclipse auch zugriff und kann die Drools Klassen in meinen Bundles verwenden.

Beispiel aus manifest.mf:

Import-Package:
 org.drools;version="5.1.1",
 org.drools.builder;version="5.1.1",
 org.drools.builder.help;version="5.1.1",
 org.drools.command;version="5.1.1", ...

Diese 4 Packages kommen aus dem Drools-API Bundle und es gibt keine Probleme. Will ich allerdings das Package "org.drools.command.impl;version="5.1.1"," aus dem Drools-Core Bundle, über den Plug-In Manifest Editor, importieren, bekomme ich folgende Fehlermeldung (im Reiter MANIFEST.MF): "Bundle 'org.drools.core' exporting package 'org.drools.command.impl' is unresolved"

Nach fast 2 Tagen Fehlersuche finde ich einfach nicht den Fehler... Warum findet Eclipse das Package über den Import-Packages-Add Button aber zeigt mir dann einen Fehler an?

Das merkwürdige ist, das ich auf meinem anderen Rechner dieses Problem nicht habe. Da importiert er die Packages ohne Probleme.

Hier noch zwei Screenshots die den Fehler verdeutlichen:
Bild1 (Plug-In Manifest Editor: Reiter Dependencies - Add Import Package)

Bild2 (Plug-In Manifest Editor: Reiter MANIFEST.MX - Fehlermeldung)

Vielen Dank schonmal im voraus,

zitzit

 

[Noctarius]

Vermutlich wird impl nicht wirklich vom Bundle exportiert um die interne Implementierung zu verstecken.

 

[Zitzit]

Doch wird es :/ Das Problem tritt auch bei anderen Packages auf. Kann es vllt. sein das Eclipse intern irgendwo eine falsche/defekte Datei benutzt? Hab den Workspace bereits gewechselt. Das merkwürdige ist halt das es auf meinem anderen Laptop ohne Probleme funktioniert.

Hier ein auszug aus der MANIFEST.MF von Drools-Core:

 org.drools.command.impl;uses:="org.drools.command,
 org.drools.command.runtime.process,
 org.drools.command.runtime.rule,
 org.drools.time,
 org.drools,
 org.drools.rule,
 org.drools.command.runtime";version="5.1.1",

 

[maki]

Wie sieht denn deine Target Platform aus?

 

[Zitzit]

Die Target Platform ist die SMILA Distribution. Im Unterordner Plugins sind die ganzen Bundles. Hieran dürfte es an sich nicht liegen, da er in der Target Platform das Core Bundle findet.

Wenn ich trotz import Fehler, mein Bundle/SMILA starte bekomme ich folgende Exceptions:

 org.osgi.framework.BundleException: The bundle could not be resolved. Reason: Missing Constraint: Import-Package: org.drools.command.impl; version="5.1.1"
...
org.osgi.framework.BundleException: The bundle could not be resolved. Reason: Missing Constraint: Require-Bundle: org.drools.core; bundle-version="5.1.1"
...
org.osgi.framework.BundleException: The bundle could not be resolved. Reason: Package uses conflict: Import-Package: com.sun.tools.xjc; version="0.0.0"
...

--> Der letzter Fehler (Package Conflict) bezieht sich auf das Drools-Core Bundle aber der ist sonst auch immer da und hat nie zu Problemen geführt.

Per OSGi (Equinox) "ss" Befehl gibt er mir aus, das er das Drools-Core Bundle findet, es aber nicht resolved ondern nur installiert ist. Die einzige Abhängigkeit von dem Drools-Core Bundle ist allerdings das Drools-API Bundle. Dieses ist hingegen active...

112	ACTIVE      org.drools.api_5.1.1
113	INSTALLED   org.drools.bpmn2_5.1.1
114	INSTALLED   org.drools.compiler_5.1.1
115	INSTALLED   org.drools.core_5.1.1
116	INSTALLED   org.drools.decisiontables_5.1.1

Sollte ich vllt. einen Ordner von meinem Galileo-Eclipse mal komplett löschen? (z.B.: configuration\org.eclipse.osgi\bundles) Können dort vllt. Dateien beschädigt sein?

 

[maki]

Was passiert denn wenn du das core bundle von der OSGi Konsole aus starten willst?

Dateien können prizipiell immer kaputt sein, 5.1.1 scheint noch recht "frisch" zu sein.

 

[Zitzit]

Bei "start 115" (115 = Core Bundle):

org.osgi.framework.BundleException: The bundle could not be resolved. Reason: Package uses conflict: Import-Package: com.sun.tools.xjc; version="0.0.0"

Hmmm... anscheind kommt er nun mit dem Package Conflict gar nicht mehr klar und startet es deshalb überhaupt nicht mehr. Aber wie kommt das von heute auf morgen? Bzw. kann ich irgendwo sehen welche Bundles "com.sun.tools.xjc" exportieren? Dann würde ich mal probieren eins aus zu schalten. In der Manifest.MF des Core Bundles sehe ich auch gerade das keine Version für dieses benötigte Package angegeben ist (deshalb version="0.0.0"). --> Zusätlich ist noch die Option: DynamicImport-Package: * gesetzt.

Aber ist nciht genau dies der vorteil von OSGi? Das man mehrere gleiche Packages haben kann und OSGi wählt dann einfach eins aus? (zumindest habe ich den Grundgedanken so verstanden)

 

[Gelöschtes Mitglied 5909]

mach mal packages com.sun.tools.xjc

 

[Zitzit]

Auf meinem anderen Laptop (L2) habe ich nun die selben Probleme...

Auszüge von meinem anderen Laptop (L2):

com.sun.tools.xjc; version="2.1.7"<com.springsource.com.sun.tools.xjc_2.1.7 [9]>
  com.unihildesheim.iis.integration.drools.impl_0.7.0 [72] imports
  org.drools.api_5.1.1 [113] imports
  org.drools.core_5.1.1 [114] imports

Meine Bundles (71: Interfaces 72: Implementierung):

71	ACTIVE      com.unihildesheim.iis.integration.drools_0.7.0
72	RESOLVED    com.unihildesheim.iis.integration.drools.impl_0.7.0

Drools Bundles:

113	ACTIVE      org.drools.api_5.1.1
114	ACTIVE      org.drools.compiler_5.1.1
115	ACTIVE      org.drools.core_5.1.1
116	ACTIVE      org.drools.decisiontables_5.1.1
117	ACTIVE      org.drools.osgi.wrapper.jxls-reader_0.9.8
118	ACTIVE      org.drools.osgi.wrapper.mvel2_2.0.16

Derzeit habe ich diverse Drools Bundles sowohl in der Target Platform (Bin/Jar Format) als auch per Maven-SRC-import im Workspace. Egal ob ich die Bin oder Src Bundles starte, erhalte ich dieselben Validierungsfehler (auf beiden Laptops). Hier ein Screen der Bundle Validation (in Run-Configuration):

Auf dem einen Laptop (L2) startet er alle Drools Bundles aber mein Implementierungs-Bundle nicht (siehe oben, Bundle ID:72). --> Trotz der Validierungsfehler (siehe Bild). Das manuelle starten per "start 72" funktioniert nicht, da er dann diverse BundleExceptions schmeißt:

org.osgi.framework.BundleException: The activator com.unihildesheim.iis.integration.drools.impl.activator.Activator for bundle com.unihildesheim.iis.integration.drools.impl is invalid
...
Caused by: java.lang.NoClassDefFoundError: BundleActivator
...

Allerdings finde ich dieses Verhalten wiederum sinnig, da er mit ja schließlich in der Manifest.MF die Package-Import Fehler anzeigt.

Auf dem anderen Laptop (L1) startet er erst garnicht die Drools Bundles und wirft die besagten Fehler aus den vorangegangenen Posts.

Auszüge von meinem anderen Laptop (L1):

com.sun.tools.xjc; version="2.1.7"<com.springsource.com.sun.tools.xjc_2.1.7 [9]>

(Die benötigten imports vom Core und Compiler Bundle werden nciht aufgelistet weil diese nicht gestartet wurden, denk ich mal?)

Meine Bundles (71: Interfaces 72: Implementierung):

71	ACTIVE      com.unihildesheim.iis.integration.drools_0.7.0
72	INSTALLED  com.unihildesheim.iis.integration.drools.impl_0.7.0

Drools Bundles:

112	ACTIVE      org.drools.api_5.1.1
113	INSTALLED org.drools.compiler_5.1.1
114	INSTALLED org.drools.core_5.1.1
115	ACTIVE      org.drools.decisiontables_5.1.1
116	ACTIVE      org.drools.osgi.wrapper.jxls-reader_0.9.8
117	ACTIVE      org.drools.osgi.wrapper.mvel2_2.0.16

Vielen Dank jetzt schonmal für die schnelle und umfangreiche Hilfe ^^ Es wird heller im Tunnel

 

[Zitzit]

Ok, denke ich habe eine Lösung gefunden die ich jetzt versuche umzusetzen: Diagnosing OSGi uses conflicts | SpringSource Team Blog

osgi> diag 72
reference:file:/D:/workspaces/drool-smila/trunk/com.unihildesheim.iis.integration.drools.impl/ [72]
  No unresolved constraints.

osgi> diag 115
reference:file:/D:/workspaces/drool-smila/trunk/SMILA_0.7/plugins/drools-core-5.1.1.jar [115]
  No unresolved constraints.

Meine Theorie:
Wie man per Diag sieht, müsste mein Bundle (72) eigentlich starten. Da allerdings die Drools Libs einen DynamicPackage-Import für alle Packages also auch für das com.sun.tools.xjc benutzen, scheint er dieses Problem beim Diag Befehl noch nicht zu sehen, da das Drools Core Bundle das Package erst zur Laufzeit sucht. Erst wenn ich versuche mein Bundle zu starten sieht Equinox das da ein Package Conflict ist und killt den Bundle Start.

Am meisten interessiert mich jetzt vorallem ob ich am Ende mist gemacht habe oder die Drools Bundles etwas verplant haben