Make an independent bundle out of SWT SVG fragment#3131
Make an independent bundle out of SWT SVG fragment#3131HeikoKlare wants to merge 1 commit intoeclipse-platform:masterfrom
Conversation
HeikoKlare
force-pushed
the
svg-as-bundle
branch
from
46bda0c to
c700b66
Compare
| org.eclipse.swt.graphics, | ||
| org.eclipse.swt.internal;x-internal:=true, | ||
| org.eclipse.swt.internal.image;x-internal:=true, | ||
| org.eclipse.swt.internal.image;x-friends:="org.eclipse.swt.svg", |
There was a problem hiding this comment.
You would need something here to wire SWT+SVG bundles usually like
Require-Capability: osgi.extender;filter:="(&(osgi.extender=osgi.service loader.processor)(version>=1.0.0)(!(version>=2.0.0)))",
osgi.serviceloader;filter:="(osgi.serviceloader=org.eclipse.swt.internal.image.SVGRasterizer)";osgi.serviceloader="org.eclipse.swt.internal.image.SVGRasterizer"
(maybe make it optional if we think SVG rasterizer is really an optional feature)
Then swt.svg would need this in the manifest:
Provide-Capability: osgi.serviceloader;osgi.serviceloader="org.eclipse.swt.internal.image.SVGRasterizer";register:="org.eclipse.swt.internal.image.SVGRasterizer";type=jsvg
There was a problem hiding this comment.
Indeed, thank you. That's something that is required now that the SVG part is not a fragment but a separate bundle such that both use independent class loaders.
What I don't fully get is why there is now a cycle detected:
Edge between 'Vertex{label='org.eclipse.platform:org.eclipse.swt.svg:3.132.100-SNAPSHOT'}' and 'Vertex{label='org.eclipse.platform:org.eclipse.swt:3.133.100-SNAPSHOT'}' introduces to cycle in the graph org.eclipse.platform:org.eclipse.swt:3.133.100-SNAPSHOT --> org.eclipse.platform:org.eclipse.swt.svg:3.132.100-SNAPSHOT --> org.eclipse.platform:org.eclipse.swt:3.133.100-SNAPSHOT
The SWT bundle has an (optional) requirement for the service provider capability that is provided by the SVG bundle and the SVG bundle of course requires the SWT bundle. Since the former is optional, I would have expected that this is okay. Is that against the specification?
When starting a runtime from the IDE, this all works fine. The SWT bundle starts first, as the SVG bundle depends on it. Then the SVG bundle starts and provides the service. Does that only work by accident?
There was a problem hiding this comment.
Oh, it's the issue that you have reported already. I missed to link that...
There was a problem hiding this comment.
Since the former is optional, I would have expected that this is okay
One can disable optional see https://tycho.eclipseprojects.io/doc/latest/target-platform-configuration/target-platform-configuration-mojo.html#dependency-resolution + https://github.com/eclipse-tycho/tycho/blob/main/target-platform-configuration/src/main/java/org/eclipse/tycho/target/DependencyResolutionConfiguration.java + https://github.com/eclipse-tycho/tycho/blob/main/tycho-api/src/main/java/org/eclipse/tycho/OptionalResolutionAction.java but I'm not 100% sure it is working as this feature is very seldom used
Is that against the specification?
In general the OSGi specification only define runtime behavior never compile / package behavior! Also "optional" has no meaning at compile time because you can't "optionally compile" a class so most often optional is actually mandatory to build the bundle except rare cases (e.g. pur reflection usage or case like this).
When starting a runtime from the IDE, this all works fine.
Yes runtime is easy, because there is only that all wiring must be fulfilled and there is no need for one thing being defined before the other and one can easily have cycles. But for compilation we need a strict cycle free graph of projects. Technically one would be able to compile such setups as one big project, but this conflicts of course with the maven reactor project concept. Of course it won't be a problem at all if swt + swt.svg would be compiled independently ... so it is not always easy.
Does that only work by accident?
No it does work exactly as one would suppose it to work, we have similar problems with p2.inf and some tricks to avoid it but not have such thing (yet) for the generic requirement/capability model of OSGi, what would generally would be superior to the p2.inf approach because p2.inf only works at installation time (thats also why I proposed this in the first place instead of rely on p2.inf or features).
So to summarize: Yes it should work and we have good reasons to make it work and I hope to find some free time to implement something soon (so don't hesitate to ping me if I forget :-)
HeikoKlare
force-pushed
the
svg-as-bundle
branch
from
c700b66 to
50cab95
Compare
org.eclipse.swt.svg was implemented as a fragment for the SWT host. This requires a complex setup due to the SVG fragment depending on the effective SWT API provided by the native fragments. With the SVG rasterizer being provided via an OSGi capability anyway, the reason for having the SVG bundle as a fragment became obsolete. This change makes org.eclipse.swt.svg an ordinary bundle. The according tests are extracted into a separate bundle as well, making the SWT tests properly independent from the tests for the specific SVG rasterizer. Contributes to eclipse-platform#3129
HeikoKlare
force-pushed
the
svg-as-bundle
branch
from
50cab95 to
cb670d6
Compare
2 participants
org.eclipse.swt.svg was implemented as a fragment for the SWT host. This requires a complex setup due to the SVG fragment depending on the effective SWT API provided by the native fragments. With the SVG rasterizer being provided via an OSGi capability anyway, the reason for having the SVG bundle as a fragment became obsolete.
This change makes org.eclipse.swt.svg an ordinary bundle. The according tests are extracted into a separate bundle as well, making the SWT tests properly independent from the tests for the specific SVG rasterizer.
Contributes to #3129