Updated gmbal with fixed jpms and osgi

[dmatej]

• gmbal-api compiles, but to run we need the implementation of ManagedObjectManagerService loaded by ManagedObjectManagerFactory. Such implementation exists just one if I am not mistaken.
• We should change some things later, ie. use own fake implementation for testing to detach from gmbal dependency.
• There is some slow progress to make the dependency management easier and more logical, JPMS enforces and helps with this direction.
• See also https://github.com/eclipse-ee4j/orb-gmbal/releases/tag/4.1.0 and especially Fixed cyclic dependency between api and impl forbidden by JPMS orb-gmbal#56
• Note that previous state was dysfunctional, GlassFish worked with Metro because JPMS was removed from the webservices-osgi.jar file used by GF.
• This PR is a first step; more are needed, but probably will not affect Metro+RI, because they are related rather to corba-orb runtime lifecycle and insane lazy init using incompletely initialized instances, which is pretty fragile.
• Note: metro-wsit using this snapshot passed own tests locally, however I will yet push there a PR bound to this change. It is still rather a bugfix than a breaking change.

[lukasj]

• gmbal-api compiles, but to run we need the implementation of ManagedObjectManagerService loaded by ManagedObjectManagerFactory. Such implementation exists just one if I am not mistaken.

ManagedEnpoint which requires the gmbal implementation is in wsit, this project needs APIs only to define contracts. There is no need for an implementation.

• We should change some things later, ie. use own fake implementation for testing to detach from gmbal dependency.

replace gmbal as such with something better?

• There is some slow progress to make the dependency management easier and more logical, JPMS enforces and helps with this direction.
• See also https://github.com/eclipse-ee4j/orb-gmbal/releases/tag/4.1.0 and especially Fixed cyclic dependency between api and impl forbidden by JPMS orb-gmbal#56

this project does not care how it is implemented on the gmbal side as long as there exist two jars:

• small API only jar this project can depend on
• an implementation only jar which those requiring management (and have wsit) can just put on the path (class/module) to make it work

• Note that previous state was dysfunctional, GlassFish worked with Metro because JPMS was removed from the webservices-osgi.jar file used by GF.

it didn't work on the GF side because the only reason webservices-osgi.jar exists is GF, which for very long time wasn't ready for JPMS. It worked very well - after this change - on the helidon side some 4-5 years ago (you can use this as a starting point should you want to reproduce the behaviour)

[dmatej]

It was not true, it did not work without it, now it is possible to get rid of it. That is the mess in dependencies I was talking about. It was masked by gmbal, because both gmbal and gmbal api used same module name, that is why you also had to exclude the API (not the impl).

[lukasj]

can you be more specific about what did not - with appropriate excludes - work? what was the error message?

helidon + gmbal-api + jaxws-ri - no MOM
helidon + gmbal + wsit - MOM endpoint started successfully

(on tomcat as well, but that is not jpms based)

That is the mess in dependencies I was talking about.

metro is not to be blamed for this state, it used what gmbal provided. It complained long time ago. It submitted temporary fixes long time ago. Now, after ~5years, someone wakes up, gets back and complains that metro is wrong. Seriously?

because both gmbal and gmbal api used same module name, that is why you also had to exclude the API (not the impl)

this was intentional - expected to be temporary - change to make metro working on JPMS as was requested and required by helidon (and other customers). gmbal project maintainers were expected to fix it the right way at their convenience (or when it actually happens to have some active maintainer), that is by keeping 2 artifacts available for its clients (API and Impl artifact; like there are those for jakarta APIs and impls). Providing one jar is not ideal as it increases jar size (important thing for some customers)

NOTE: touching the "bundle" jar back then would have negative impact on the glassfish team and release with high risk of possible regressions; I can agree that the solution wasn't/isn't ideal, yet it considered more risks than it looks