Module name for framework implementation

[bjhargrave]

Original bug ID: BZ#3144
From: @tjwatson
Reported version: R8

[bjhargrave]

Comment author: @tjwatson

During the OSGi Connect review there was a discussion about how a bundle could have a module-info.class as well as a bundle manifest file. In such a scenario it is unclear what a bundle would require to access org.osgi.framework packages that are provided by a framework at runtime.

Three possibilities were discussed:

1. Mandate a module name for all framework implementations if they are a JPMS module. For example, org.osgi.framework. Nobody liked this option. Implementations should have their own unique name, equinox, felix, Knopflerfish.

2. Force all framework implementations that are JPMS modules to not package the org.osgi.framework packages and instead have them require the (automatic module) osgi.core. Nobody liked this option because frameworks have always packaged the org.osgi core packages in their implementation and move that out to another required artifact does not seem appealing

3. Specify a module name to represent the framework and each implementation can provide their module of that name that does a transitive requirement on their framework specific module. (e.g. module name osgi.framework) this way a module-info for a bundle could do a requires osgi.framework and which ever implementation is on the module path will be used.

Option 3 is the most appealing, should we spec a name in R8 for something like this?

[bjhargrave]

Comment author: @bjhargrave

For option 3, each framework impl would need to publish its own artifact which has the standard module name and transitively required the framework impl's implementation specific module name.

So the question is what is the standard module name? I would suggest "osgi.framework".

osgi.core is already known as the name of the core api-only artifact.

org.osgi.framework is already the automatic module name (in the current build) of the org.osgi.framework artifact.

[bjhargrave]

Comment author: @tjwatson

(In reply to BJ Hargrave from comment BZ#1)

For option 3, each framework impl would need to publish its own artifact
which has the standard module name and transitively required the framework
impl's implementation specific module name.

So the question is what is the standard module name? I would suggest
"osgi.framework".

osgi.core is already known as the name of the core api-only artifact.

org.osgi.framework is already the automatic module name (in the current
build) of the org.osgi.framework artifact.

Yes osgi.framework is what I was thinking. For Atomos I did this, but prefixed the name with atomos (i.e atomos.osgi.framework). And the atomos runtime just requires atomos.osgi.framework and is able to run with either Equinox of felix this way: https://github.com/tjwatson/atomos/tree/master/atomos.osgi.frameworks

A standard name of "osgi.framework" would be better.

[bjhargrave]

Comment author: @rinswind

Now that I have time to look at the options in detail this doesn't seem right.

Isn't it true that in the world of JPMS the module name is supposed to uniquely identify an artifact's purpose much like the bundle symbolic name in OSGi?

If I understand correctly option 3 would be like requiring every framework implementation to additionally provide a bundle with the symbolic name "osgi.framework" that has totally different dependencies from other peer such bundles. That will be just as confusing in the JPMS world as it is in the OSGi world. How will the maven GAV be derived from the artifact at the very least?

I think that as much as we don't like it we must split the core API into its own JAR (option 2). That is the only solution that does not go against JPMS.

[bjhargrave]

Comment author: @pkriens

I agree that the idea to have multiple programs with the same module name will be confusing and error prone. I also fail to see why today the extra org.osgi.framework holding the API module is in anyway a problem?

[bjhargrave]

Comment author: @bjhargrave

A module name is API. So there is no reason why multiple artifacts cannot offer the same module name. In open source, this can be done for licensing reasons.

People just need to pick the right artifact. The artifact for Equinox or the artifact for Felix. Their code will see the osgi.framework module name that they can require.

[bjhargrave]

Comment author: @tjwatson

The module name is API, just like a package is API. We certainly allow multiple artifacts bundles export the same package in OSGi. I fail to see the difference here for the osgi.framework module name.

Aside from that, I think forcing impls to split out the org.osgi API from the framework impl will make all the existing use cases of OSGi more difficult to setup. I don't think enabling a standard module name for bundles to require is worth the risk for the existing use cases of OSGi today in a non JPMS world. That is why I think option three is the most reasonable thing to do. Another option is to just let the community try option 3 out in the open and not spec it for now. We can see if it has any traction. Maybe there will be zero interest and we will not see the need to spec anything.

[bjhargrave]

Comment author: @bjhargrave

We also cannot require framework impls to separate out the OSGi API since we have always allowed framework impls to replace impls in the API. FrameworkUtil.createFilter is the poster child for this. Framework impls need to be able to customize the OSGi API impls which means there cannot be one canonical module holding the OSGi API which all framework impls must require. So the reality is that option 2 is not actually feasible.

So the only practical choices are 1 and 3. Both of which are different artifacts providing the one module name (e.g. "osgi.framework").

[bjhargrave]

Comment author: @pkriens

@ bj I would have no problem if a framework vendor provided his own implementation of the org.osgi.framework module. I agree that that was meant in JPMS. However, it requires the module to be identical I think. It would imho imply that a framework implementation would not have even have a single extra capability.

This works well for API only but I doubt Equinox could live without some of its extensions that are widely used?

A module name must stand for a fixed set of capabilities. Otherwise, you need out of band communication to know you got the right module, the sole purpose of a module name. Once you remove that constraint, what is the purpose? You might as well use the SHA.

[bjhargrave]

Comment author: @bjhargrave

(In reply to Peter Kriens from comment BZ#8)

@ bj I would have no problem if a framework vendor provided his own
implementation of the org.osgi.framework module. I agree that that was
meant in JPMS. However, it requires the module to be identical I think. It
would imho imply that a framework implementation would not have even have a
single extra capability.

This works well for API only but I doubt Equinox could live without some of
its extensions that are widely used?

A module name must stand for a fixed set of capabilities. Otherwise, you
need out of band communication to know you got the right module, the sole
purpose of a module name. Once you remove that constraint, what is the
purpose? You might as well use the SHA.

So I am unclear if you are saying there is no solution here? Or that solution 1 is better or worse than 3? Or that we must do solution 2 and break the past promise to framework implementors that they can modify the implementation details of the OSGi API?

I want to support running OSGi frameworks in JPMS but we cannot require too many changes of past promises to enable it.

As for multiple artifacts having the same module name (e.g. osgi.framework), there can be compileOnly artifacts which expose the core API at compile time and runtime artifacts which are the framework implementations which can supply a superset of the capabilities of the compileOnly artifact. This is basically what we do today with osgi.core.jar as the compileOnly artifact and any framework impl as the runtime artifact. I don't see why this is not also possible in the JPMS world.

[bjhargrave]

Comment author: @tjwatson

CPEG F2F call: We agreed to add a module name (automatic) to the osgi.core JAR. Its module name will be "osgi.core". Framework implementations are then free to provide their own module that also provides the same packages as the osgi.core JAR. This module may be a facade module that transitively requires the actual implementation of the framework.

We decided against adding any prescriptive text to the specification mandating a framework implementation must provide such a module. For now the spec is only defining the module name of the osgi.core JAR.

Leaving open until the osgi.core JAR is fixed to add the automatic module name header.