Add back exports to the org.eclipse.swt host #1032
Conversation
Some projects, like BND tools, will avoid using require-bundle at great lengths. This becomes problematic when the APIs they want to use do not version there `Export-Package` properly. Many Eclipse projects, including SWT, do not version their API packages. They only version their individual bundles with respect to semantic versioning. For BND they resorted to using `Import-Package` with the `bundle-version` and `bundle-symbolic-name` of the host. This "worked" because the SWT API packages were defined in the `Export-Package` header of the host bundle. But now with PR eclipse-platform#1008 this changed and the host bundle no longer defines the exported packages. The end result is BND tools is now broken and has many unresolvable bundles. Until this is sorted out, this PR simply adds back the `Export-Package` header of the SWT host. The longer term solution should be to properly version SWT API packages so that consumers of the API can properly use `Import-Package` to depend on the API.
tjwatson
force-pushed
the
exportPackageSWT
branch
from
dc1b930
to
d068bc0
Compare
|
The quality-gate errors in Jenkins are somewhat expected, since it was setup newly for SWT and has to settle first. |
So effectively they using (yes I know that there are still slight differences)
an immediate solution would be to simply always export all packages with the bundle version. |
|
This change adds now 19 API errors on org.eclipse.swt.gtk.linux.x86_64, saying basically that all workspace types from Changing export to I'm alone who sees the problem? Or is this Linux specific? |
|
I see this now:
|
Yes adding back Changing it to If non one of you adds the |
Exact. So it should be fixed => #1038 |
Sorry about that. I was told the |
|
Most likely this change also causes following issue: eclipse-platform/eclipse.platform.ui#1654 |
@tjwatson can you explain what component complains here? As I'm currently looking into the resolver I'm also looking what the spec says and there one finds:
For me it looks like the "complainer" here is not respecting that rule and only looks at packages from the host but not consider those contributed by fragments. |
|
I remember that part of the specification, but I don't believe it to be implementable. At one point I thought I removed that from the core specification. No framework implements that behavior, because I believe it to be unimplementable. And clearly there is no TCK for it. |
Some projects, like BND tools, will avoid using require-bundle at great lengths. This becomes problematic when the APIs they want to use do not version there
Export-Packageproperly.Many Eclipse projects, including SWT, do not version their API packages. They only version their individual bundles with respect to semantic versioning.
For BND they resorted to using
Import-Packagewith thebundle-versionandbundle-symbolic-nameof the host. This "worked" because the SWT API packages were defined in theExport-Packageheader of the host bundle. But now with PR #1008 this changed and the host bundle no longer defines the exported packages. The end result is BND tools is now broken and has many unresolvable bundles.Until this is sorted out, this PR simply adds back the
Export-Packageheader of the SWT host. The longer term solution should be to properly version SWT API packages so that consumers of the API can properly useImport-Packageto depend on the API.