They support OSGi due to liberty's requirements. How they do it is up to them. Can you please elaborate on what is wrong with the current OSGi headers?
Nop, liberty does it all wrong. They force setGlobalProvider in the API and this is not needed as any geronimo spec jar or aries shows. This leads to an unsafe user accessible API which is not thread safe and a server destructor :(.
And the issue with Java 9 is that you can end up with multiple copies of the packages.
This is not really an issue, no more than today actually since it is the same ones with the same content.
We should be fixing the MP spec JARs rather than implementing our set of JARs. It creates confusion and will lead to inability to run on Java 9.
Last point is wrong since we'll put the same automatic module name.
I'm fine with the first proposal if we have a way to guarantee 1. we can get the releases fast enough (< 2 weeks) and 2. they will embrace spifly+javacontract on OSGi side. Any of you (more involved in MP community) able to check that out before we close that topic please?
Well b doesn't solve 3, any way we get karma to do the releases? This would solve that neatly.
All fair points, but
a.) I don't want to host org.eclipse sources at Apache
b.) We can just ship a PR to add those features over there
c.) point 4 should not be the case.
So I'd vote -1
> Am 04.06.2018 um 09:09 schrieb Romain Manni-Bucau <rmannibucau@xxxxxxxxx>:
> Hi guys,
> we have 4 MP implementations I think (failsafe, config, jwt-auth and opentracing) and 2 of them reused eclipse api jar and 2 uses a geronimo flavor.
> I'd like us to discuss which flavor we want to align all of them.
> The fact to reuse the API reduces the code we hosts which is not bad but has these drawbacks:
> 1. when a loader is involved we can't enhance it for our consumers (like aries) to be compatible with other mecanism than plain java standalone (+ standard java(ee) mecanism like lib/<spec>.properties which is sometimes used in users land)
> 2. geronimo always provided a good entry point to be OSGi friendly. I saw that some MP@eclipse jar provided some OSGi work but they rely on a dependency we don't want in all not OSGi apps + they don't embrace what our consumers do (spifly+javacontract we will merge soon)
> 3. it is very slow to have an eclipse release (opentracing and jwt auth were a pain and even led to use tck in snapshot to launch the release after having waited weeks)
> 4. if there is some default hardcoded (dont think it is the case yet but it can likely be appended in 1 to be consistent with the javaee/jakartaee behavior) then we will want to put our default and not the RI one
> At the end the cost to have the spec jar is almost nothing to not say really nothing so I'm in favor of ensuring we always host it.
> Romain Manni-Bucau
> @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book