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
Adds Feature #1568 - [OSGi] Opting in to Service Loader Mediator #1569
base: master
Are you sure you want to change the base?
Conversation
@timothyjward As an OSGi expert, could you please at least verify if my assumption and approach for the fix is correct? I tested it locally in an Maven based OSGi-application, and it works fine. But getting feedback from you would be very beneficial. |
Hi - I think the extender requirements that you have added look fine, but the implementation seems to be missing For reference I think you would need entries for each of the implementations registered in https://github.com/eclipse/eclipse-collections/tree/master/eclipse-collections/src/main/resources/META-INF/services There are a lot of these, so you may wish to consider having bnd generate all this for you (including META-INF/services files) using the |
@timothyjward I will check if I can use the |
I adapted the request from @timothyjward and use This also revealed a current issue in the eclipse-collections bundle. The following files are currently included in
|
@nikhilnanivadekar |
@fipro78 trying to understand the PR. Is it possible to logically squash the commits? Multiple commits are ok, but some of them are overwritten and reviewing would be cumbersome. Also, if you wouldn't mind explaining what will be the new process for p2 update site and to contribute to the Simrel repo? I am not an expert in this area. So, I will need (a lot of) help as I learn. Thanks! |
af243ee
to
ad5c9c1
Compare
After some struggles, I hope I have correctly squashed the commits.
Well, with this PR the p2 update site is created from the With regards to contribute to the Simrel repo, this PR actually has no impact. What this PR does is, it ensures that the artifacts, that are published to Maven Central, can also be used in an OSGi context. This was not really possible as of now, because the API retrieves services from the Impl, but they reside in different bundles, and therefore we have classloader issues. That is why the previous EBR approach in Whether Eclipse Collections become part of Simrel or will be included in Eclipse Orbit, is out of the scope of this PR. But without additional build steps, it should be easy to include the artifacts from Maven Central there. It would be only needed to consume those artifacts, as they are OSGi bundles. Of course that need to be validated again, to be sure that it is really working. I suppose @merks asked whether there is a Maven repository to consume the artefacts before they are actually released, so it can be verified how easy it would be. And maybe he can then also give some more information with regards to including Eclipse Collections to Orbit or Simrel. In the end, the question is, who is responsible for the publishing of the p2 update site. And IMHO that depends on how easy it becomes to consume the artifacts from Maven Central, rather then needing to create a wrapped bundle. @merks |
PDE, with m2e's help, as well as Tycho, support specifying Maven dependencies in a *.target. Orbit uses that specifically here: https://github.com/eclipse-orbit/orbit-simrel/blob/main/maven-osgi/tp/Maven.target As background, this file is generated/updated automatically by looking at the *.target of various SimRel projects and looking at Maven Central for new versions. As part of that analysis, the following target is also considered: https://github.com/eclipse-orbit/orbit-simrel/blob/main/maven-osgi/tp/other/MavenSupplement.target So if Eclipse Collections publishes well-formed OSGi artifacts to Maven Central we can trivially include it in MavenSupplement.target so that it's generated into Maven.target and in the end, is available in these Orbit p2 repositories: https://download.eclipse.org/tools/orbit/simrel/maven-osgi/ Note that is is a convenience for the consumers because the consumers can include such dependencies directly in their own *.target, in which case they are also responsible for PGP signing those artifacts, which Orbit also does as an additional convenience. Once that's in place, the Eclipse Collection's SimRel contribution should be removed and any other project relying on those bundles, must contribute them via the p2 repository of their own SimRel contribution. So I'm happy with this path forward. The overhead for Orbit is trivial and is just done once, after which updates will be automatically generated. |
Hi @fipro78, thanks for spotting this. I don't believe these classes ever existed. IIRC, we had a discussion a long time ago around the benefit of having boolean to anything Map and decided it wasn't worth coding or generating. These must have been mistakenly added to the services.
|
Automatic-Module-Name
tojpms-module-info
With this the module-info.class gets generated by Bndtools to the bundle file. This should resolve Getting rid of Automatic Modules? #1451 then.
@aQute.bnd.annotation.spi.ServiceProvider
annotation to the factories. This annotation triggers the generation ofRequire-Capability
header for the Service Loader MediatorProvide-Capability
header for all provided servicesMETA-INF/services
META-INF/services
don't contain provider configuration files of services that do not exist anymore (see in a comment below)p2-repository
module which uses EBR.p2-feature
to build a p2 update site via Tycho.Bundle-Developer
in the manifest is also suitable.