Closed HannesWell closed 2 years ago
This requires https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/pull/247 to build successfully. But since we have not yet talked about this particular Plug-in I would like the clarify first if this change should be done or if there are reasons that speak against it.
Additionally some more features have to be updated to keep the sources of org.osgi.service.prefs
available.
This requires eclipse-equinox/equinox.framework#39 to build successfully.
This is PR 39. Perhaps you mean another PR?
This requires eclipse-equinox/equinox.framework#39 to build successfully.
This is PR 39. Perhaps you mean another PR?
Ups, indeed. I meant: https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/pull/247
Since you require the osgi prefs API bundle at
1.1.0
, the import package version should match. It is currently1.1.1
Thanks for the hint. Shouldn't I remove the Import-Package entirely to not have bot Import-Package and Require-bundle of org.osgi.service.prefs?
Shouldn't I remove the Import-Package entirely to not have bot Import-Package and Require-bundle of org.osgi.service.prefs?
I am not sure if Require-Bundle with reexport allows for substitution? @tjwatson? If it does, then having the Import-Package is good since it provides more room for the resolver.
I am not sure if Require-Bundle with reexport allows for substitution? @tjwatson? If it does, then having the Import-Package is good since it provides more room for the resolver.
I think this is a grey area. I know the resolver will make sure the class space is consistent for the importing bundle. But I don't recall what would happen for the bundles requiring the re-exporter (org.ecipse.equinox.prefs
in this case). I don't recall if they get wired to the target of the import package wire or directly to the reexported bundle.
Given that the build succeeds now (the dependencies were added to the Eclipse-SDK-target), do you have any objections against this change? If not I would like to submit it.
I will created corresponding PRs to include the org.osgi.service.prefs
into those features that contain org.eclipse.equinox.preferences
already to make the sources available.
Thanks everyone!
For completeness, I created/updated the following PRs to include org.osgi.service.prefs into those features that already include o.e.equinox.preferences
:
We should move the application admin tests out of org.eclipse.osgi.tests
and into some dedicated org.eclipse.equinox.app.tests
project. Of coarse the test failures in the org.eclipse.osgi.tests
would have been caught during the this PR build if we had combined framework
and bundles
repos also.
We should move the application admin tests out of
org.eclipse.osgi.tests
and into some dedicatedorg.eclipse.equinox.app.tests
project. Of coarse the test failures in theorg.eclipse.osgi.tests
would have been caught during the this PR build if we had combinedframework
andbundles
repos also.
Sounds good. Having finer grained test-plugins is probably at all not a bad idea. Yes combined repos would have helped too, but the merge is not too far away.
Similar to the other changes explicitly discussed in https://github.com/eclipse-equinox/equinox/issues/18, this replaces the embedded OSGi-sources of
org.eclipse.equinox.preferences
by the corresponding osgi-bundle from Maven-Central.As a side effect this updates the versions of
Since many other plug-ins are likely requiring
o.e.equinox.preferences
and are using the classes inorg.osgi.service.prefs
that bundle is required and re-exported.