Provide guidance for OSGi integration

[lukasj]

Is your feature request related to a problem? Please describe.
Different spec/impl projects currently use different approaches to integrate with OSGi frameworks

Describe the solution you'd like
Platform provides/defines consistent approach to integrate with OSGi for those who wants to opt-in supporting it, with minimal required OSGi runtime version eventually

Describe alternatives you've considered
Use org.glassfish.hk2.osgiresourcelocator, use the OSGi ServiceLoader mediator standard, follow http://docs.osgi.org/reference/portable-java-contracts.html#references

Additional context
jakartaee/saaj-api#43 (comment)

AB#76

[keilw]

@lukasj Do we even know, how many Jakarta EE specs (APIs) currently expose an OSGi bundle?
I only had a brief look at some where the JPMS module name was in question, there both names usually match in the MANIFEST, but we did not cover all of them or mandate the OSGi bundle for Jakarta EE 9.

[lukasj]

Hard to say - I'm aware of at least 11. I'm not asking for this to be mandatory. The goal is - if the spec decides to support OSGi, then it should follow the pattern used by other specs included in the platform, so the end-developer experience is the same regardless of which particular Jakarta spec is used and creation of repackaged bundles with correct OSGi metadata is not needed (ie Eclipse RCP used to provide correct OSGi bundles for use within Eclipse Platform based apps through Eclipse Orbit). This is also something what probably does not have to be directly in the spec but instead be included in the architecture document.

[keilw]

So it's more integration support for implementors or end users`?

[lukasj]

implementors need to know what to provide for end users to be able to use it. End users may vary from Application Server providers, through Eclipse RCP based apps to Public Transport industry (ie software in high-speed trains developed in Germany does heavily rely on OSGi)

[keilw]

Also similar to other discussions including #329 where do you think those would best go or be documented in?
Because special problems like these JDK bugs are also mostly concern to implementors and endusers, particularly those who use MRJs. I am not sure, if any API needs that for the time being, and if a strong recomendation or even force to put the module-info into the root folder might do for them.

[lukasj]

Also similar to other discussions including #329 where do you think those would best go or be documented in?

I'll repeat myself:

This is also something what probably does not have to be directly in the spec but instead be included in the architecture document.

OSGi metadata do belong to META-INF/MANIFEST.MF

[keilw]

Yes but currently they are not mandated, maybe they never will?

Which architecture document, where does that fit into the deliverables of https://jakarta.ee/specifications/platform/9.1/ or beyond?

[lukasj]

Yes but currently they are not mandated, maybe they never will?

Read what I'm asking for once again, please. I'm by no means saying that support for OSGi must or should be mandated. I'm saying that IF the spec decides, or opts-in, to support OSGi, THEN the platform should define what sort of metadata - whether hk2.osgiresourcelocator, OSGi ServiceLoader mediator standard, Portable Java Contracts Definitions or something else - should the spec use in order to be consistent with other specs within the platform which already decided to support it. Current state where some specs rely on hk2.osgiresourcelocator (ie XML WS related ones), others on Portable Java Contracts (ie Servlet) is not good. It may be also good idea to work with OSGi Alliance to update their Portable Java Contracts Definitions to reflect the move to Jakarta (rename contracts from Java* to Jakarta*) and add missing pieces there (ie JSR 67/current SOAP)

Which architecture document

the one @ivargrimstad created and which has been shown and referred to during the platform call few times already

where does that fit into the deliverables of https://jakarta.ee/specifications/platform/9.1/ or beyond?

I see no or very limited impact on deliverables

[keilw]

If the document @ivargrimstad mentioned will become part of the Jakarta EE 10 deliverables or published in some form, sure, but I don't think it's enough to only discuss this in some internal documents, it should be published with new releases, whatever you call those documents or of they become part of a spec, userguide or similar is another question.

About the OSGi stuff I understand it is quite important on the Eclipse RCP side, but I don't see it so crucial for every implementor especially compared to "Jigsaw".

[lukasj]

If the document @ivargrimstad mentioned will become part of the Jakarta EE 10 deliverables or published in some form, sure, but I don't think it's enough to only discuss this in some internal documents, it should be published with new releases, whatever you call those documents or of they become part of a spec, userguide or similar is another question.

Such document should have been created before Jakarta EE 8. It's a debt which, IMHO, should be paid rather sooner than later. It is not a deliverable for Jakarta EE 10 itself per se. It is supposed to be a guideline for, probably not only, spec projects to follow in order to satisfy platform requirements. Whether it will be delivered in the EE 10 timeframe, later or never - that is the platform's call. Just because I personally see the need for a document like this to exist, others may have different view and prefer "life in the wild".

And no, it is definitely NOT some imaginary internal document. It should be enough to attend platform call or just read call's meeting minutes, such as this one, to know the link to it. Ivar has asked for some input to it few times already.

About the OSGi stuff I understand it is quite important on the Eclipse RCP side, but I don't see it so crucial for every implementor especially compared to "Jigsaw".

During one of the calls back in January, this (OSGi stuff) has been touched briefly, with a conclusion that it may be valid input probably not for the spec but for some other kind of document. This just tries to break the silence about this topic since then.

[keilw]

You're absolutely right about those kinds of documents. Of course we all know, the resources were quite constrained back then and we're all very lucky Java EE survived in its current form to have a seemingly better future now, so good to tie some of those untied knots now...