-
Notifications
You must be signed in to change notification settings - Fork 155
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce OSGi capability to wire o.e.swt to its native fragments #490
Comments
If there is a possibility to move from p2.inf to capabilities I'm all for it. It should even allow to drop https://github.com/eclipse-platform/eclipse.platform.swt/blob/master/local-build/org.eclipse.swt.fragments.localbuild/META-INF/p2.inf hooked via https://github.com/eclipse-platform/eclipse.platform.swt/blob/master/local-build/local-build-parent/pom.xml#L36 IIUC, right? |
I think this is a great idea and worth being implemented. |
One problem is that currently the p2 requirement is disabled for the swt build as one otherwise has a cyclic dependency (
About PDE: Pde does not required this but already has had "Extensible-API" header for this but for the whole purpose because platform misused fragments as "test-fragments", in OSGi a fragment do never need any capability as it is automatically attached. This is for the sole of P2 to workaround the hack with test-fragments so actually |
In the p2.inf the circularity is prevented by the
Might the same mechanism to prevent circularity work for this new proposed approach? |
Great, I'm glad you like the idea.
The second approach is what I'm currently working on, making the fragments 'plain-maven' The
The The main problem I have with p2-instructions is that it is only poorly supported in terms of tooling and the documentation is also not very verbose. And IIRC there is some not in the doc that it is all provisional. I started to work on this and it looks promising. It has also the advantage that many similar files can be removed. I will hopefully be able to created the first draft PRs in the next days. |
Note that SWT currently is published like this: I.e., with this dependency:
So downstream consumers can generally depend directly on org.eclipse.swt. The /publish-to-maven-central/SDK4Mvn.aggran provides a preview of how the latest 4.27 I-build would be published to Maven: This is dependency is derived from the requirements represented in p2: I suspect that if this is changed as suggested here, that maybe special handling will be needed to ensure that it maps sensibly; but then again, maybe it will just work. In any case, it's something on which we should key an eye... |
Is your feature request related to a problem? Please describe.
At the moment the need of the
org.eclipse.swt
Plugin to have a platform-specific native fragment is only encoded on P2 level via p2.inf instructions or by corresponding features that containo.e.swt
and all native fragments with a corresponding platform filter.The p2-instructions ensure that when building for example a Plug-in based product that only includes o.e.swt the native-swt fragment for the platform the product is build for is also included.
This approach has the disadvantage if one has a Eclipse/OSGi-application launch configuration based on plug-ins, where the automatic inclusion of dependencies is enabled and where only the o.e.swt Plugin is either specified or is part of the depedency closure, that then the launch fails quickly because the native fragment is not included.
The reason is that PDE computes the dependencies to include, based on the required OSGi wires of the Plug-ins/Bundles. And at the moment there is no wire from the
o.e.swt
bundle requiring a native fragment. Only the other way round.To make the launch succeed one has to add the fragment for the current platform to the launch config manually, which is cumbersome.
Describe the solution you'd like
Therefore I want to suggest to introduce a OSGi capability for example named
org.eclipse.swt.native
.The
org.eclipse.swt
Plugin then has to require that capability:And each native swt fragment should provide that capbaility:
Because the swt-native fragment has platform filters only one fragment resolves on a certain platform and therefore there is only one provider of that capability, which is then required by o.e.swt.
This works well in the IDE, because PDE does only consider
Require-Bundle
andImport-Package
header for the graph from which the build order is computed and therefore there are no cycles.So far so good, the only problem is that Tycho considers generic OSGi capabilities and therefore detects cycles in the project dependencies and consequently fails the build.
In fact this the presented idea is not new and exists for decades (see for example Bug 177851 or Bug 361901 ).
And the failure of Tycho is, at least in the second bug, the reason why this approach was discarded.
But nowadays we have more possibilities. This build-cycle problem could be solved if the native-fragment projects would be converted to Maven projects that have their Manifest generated (for example by the bnd-maven-plugin). The
o.e.swt
Plugin would then add the Maven artifacts as Maven dependencies to itspom.xml
. All projects could still be build together in a mixed reactor (although at least in the verification builds for eclipse.platform.swt and eclipse.platform.swt.binaries are build in separated runs, but I assume that for the I-builds they are build together?). In the maven reactor theo.e.swt
project would just depend on all its native fragments and because the thenjar
-typed natives projects are not 'OSGi-resolved' the back-link is not established in the Maven build graph.With the latest M2E version those Maven projects can even participate in the regular PDE workspace build just like ordinary Eclipse Plugin projects, thanks to the new connectors for the bnd-maven-plugin/maven-bundle-plugin.
We already use that technique in M2E to build the maven-runtime bundles in one pass in a mixed reactor and all the mentioned things work well:
https://github.com/eclipse-m2e/m2e-core/blob/master/m2e-maven-runtime/pom.xml
This approach would allow to add the suggested required/provided capabilities and would consequently solve the launch problem in PDE. It would probably also allow to remove the p2-instructions. And it would also make it trivial to keep the Manifest-files in sync because e.g. the version of the host plugin can be set once in a variable and would then be reused and thus would ease the maintenance of the swt-native projects. IIRC there are some more SWT workarounds in the Eclipse-Platform they maybe can be removed as well.
The main blocker I see at the moment is that the Eclipse-Platform build is currently running with Tycho's classic resolver which does not support mixed reactors in Tycho 4.0 (but I hope @laeubi will make the new resolver work soon :) ). But there might be others (hopefully smaller ones) on the road.
Describe alternatives you've considered
Alternatively PDE could add support to read p2.inf instructions when computing dependencies during the launch of a Eclipse/OSGi application, but I think that would be more complicated.
PDE could also add a special SWT-case where it adds the native fragment for the current platform if o.e.swt is included, but that would just be one more workaround.
SWT could also be reworked to only have one 'multi-platform' jar (was already suggested in other places), but this would likely be a much greater effort.
@akurtakov, @mickaelistria, @laeubi what do you think? Do you see other blockers?
The text was updated successfully, but these errors were encountered: