Gemini Blueprint und Spring inkompatible Versionen

[Robertop]

Hallo zusammen,

ich versuche gerade, ein älteres Programm auf eine neuere Version vom Springframework upzudaten, habe jetzt aber leider Probleme mit Abhängigkeiten zwischen Gemini Blueprint und dem Springframework. Weil das Original Programm relativ durcheinander ist, und ich glaube, dass das Problem eher mit den Namen zu tun hat, als mit der gesamten Archtitekur, habe ich das in einem neuen Eclipse Workspace mithilfe von einer Target-Platform nachgestellt. Alle Plug-Ins, die ich verwendet habe, habe ich direkt als jar von mvnrepository.com heruntergeladen.

Meine Ausgangssituation sieht so aus:


Ziel ist es, die drei gemini Plug-Ins in der Target Plattform mithilfe des zusätzlichen Plug-Ins "Externals" mit den benötigten Plug-Ins zu versorgen. Das Externals Plug-In enthält das hier:

Bundle-ClassPath: aopalliance-1.0.jar,
  spring-aop-4.2.5.RELEASE.jar
Export-Package: org.aopalliance.aop,
 org.aopalliance.intercept,
 org.springframework.aop,
 org.springframework.aop.aspectj,
 org.springframework.aop.aspectj.annotation,
 org.springframework.aop.aspectj.autoproxy,
 org.springframework.aop.config,
 org.springframework.aop.framework,
 org.springframework.aop.framework.adapter,
 org.springframework.aop.framework.autoproxy,
 org.springframework.aop.framework.autoproxy.target,
 org.springframework.aop.interceptor,
 org.springframework.aop.scope,
 org.springframework.aop.support,
 org.springframework.aop.support.annotation,
 org.springframework.aop.target,
 org.springframework.aop.target.dynamic

Wenn man in den Run Configurations in Eclipse die Plug-Ins validiert, ohne das "Externals" eingebunden wird, dann erkennt man, dass unter anderem diese Sachen fehlen:

Missing Constraint: Import-Package: org.aopalliance.aop; version="0.0.0"
Missing Constraint: Import-Package: org.aopalliance.intercept; version="0.0.0"
Missing Constraint: Import-Package: org.springframework.aop; version="[4.2.0,4.3.0)"
...

Wenn ich jetzt das "Externals" dazu nehme, dann müssten nach meinem Verständnis zumindest diese drei Abhängigkeiten bei der Validierung verschwinden, weil sie ja ab diesem Zeitpunkt zur Verfügung stehen.
Bei org.aopalliance.aop und org.aopalliance.intercept funktioniert das auch.
Bei dem org.springframework.aop funktioniert das aber nicht.

Dasselbe Problem tritt auch bei allen anderen springframework Plug-Ins auf, die ich versucht habe einzubinden. Ich habe es schon mit mehreren verschiedenen Gemini und Springframework Versionen probiert, habe aber immer wieder dasselbe Problem.
Von meinem Gefühl her ist das Problem, dass die Bundlenamen beim Springframework nicht mehr wie früher z.B. org.springframework.aop etc. sind, sondern org.springframework.spring-aop, und das Gemini einfach immernoch die alten Namen erwartet. Das macht zwar eigentlich keinen Sinn, weil die packages selber ja noch die richtigen Namen haben, aber eine andere Erklärung fällt mir leider nicht ein.


Kennt jemand von euch das Problem, oder gibt es vielleicht irgendeine ganz bestimme Kombination von Versionsnummern, die man verwenden muss, damit es funktioniert? Gemini 2.0.0.RELEASE habe ich schon mit Springframework 4.2.0, 4.2.9 und jetzt 4.2.5 ausprobiert. Gemini 2.1.0.RELEASE habe ich mit Springframework 4.3.0 und Gemini 3.0.0.M01 habe mit Springframework 5.3.8 ausprobiert. Der Fehler ist immer der gleiche.

 

[Robertop]

Also ich habe jetzt noch erfolglos ein paar andere Dinge ausprobiert und hatte schließlich noch eine andere Idee.

Bei den Plug-Ins von gemini blueprint sind ja immer auch Source-JARs dabei, die soweit ich weiss beim debugging benutzt werden. Mein Gedanke war jetzt, dass ich doch theoretisch meine eigenen Plug-Ins mit genau diesen Sourcen erstellen kann, sodass ich dann nachträglich selbst die Dependencies so ändern kann, dass es funktioniert.

Dazu jetzt direkt meine Frage:
Ist das generell möglich, dass man anstatt einer fertigen JAR von einem Plug-In ein selbst erstelltes Plug-In mit den Sourcen benutzt? Und wenn nein, dann wieso nicht? Oder muss man eventuell noch weitere Sachen einbinden, die in der fertigen JAR vorhanden sind, aber die man bei den Sourcen nicht sehen kann?

Bei meinem Versuch habe ich nämlich zuerst die Sourcen der drei Gemini Plug-Ins .core, .extender und .io genommen, die im fertigen System funktionieren, bin aber dort in den Sourcen direkt auf Build-Fehler gestoßen, die ich mir nicht erklären kann:
- Bei den Sourcen bekomme ich mehrere Buildfehler, weil in Gemini die Klasse "Properties" verwendet wird, die OSGi Funktionen aber "Dictonairy" erwarten.
- In den Sourcen gibt es eine Konstante zu dem Blueprint Schema "http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd", dass beim Starten zu einem Fehlschlag führt, weil er versucht den Redirect zu Parsen anstatt das neue Ziel.

Das sind ja beides Sachen, die man beim Debuggen der fertigen JARs genauso auch im Programmcode sehen kann, dort aber problemlos funktionieren. Gibt es da logische Erklärung für?

 

[mrBrown]

Ist das generell möglich, dass man anstatt einer fertigen JAR von einem Plug-In ein selbst erstelltes Plug-In mit den Sourcen benutzt? Und wenn nein, dann wieso nicht? Oder muss man eventuell noch weitere Sachen einbinden, die in der fertigen JAR vorhanden sind, aber die man bei den Sourcen nicht sehen kann?

Zwei Dinge machen da potentiell Probleme:
1: Der Build-Prozess ist in den Sourcen nicht komplett beschrieben, je nachdem was gemacht wird, reichen dann die Sourcen allein nicht.
2: Je nachdem wo und wie dein eigenes Projekt gebaut wird, musst du dafür sorgen, dass die Dependencies auflösbar sind. Potentiell musst du die also mit eigenen Koordinaten irgendwo publishen, damit's da keine Konflikte gibt.

Das erste kannst du aber einfach lösen: die Eclipse-Sachen sind Open-Source, die kannst du also einfach auschecken und selber bauen, ohne die Sources-Jar.