I'm with Romain on this one. There is a ticket open for various MP specs. We should evaluate this and then push for it to be fixed.
LieGrue, strub > Am 04.06.2018 um 15:09 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: > > > > Le lun. 4 juin 2018 à 13:45, John D. Ament <johndam...@apache.org> a écrit : > 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 > :(. > We need https://github.com/apache/geronimo-specs/pull/9 and at least > SPI-Provider header, spifly can be nice too - is used today. > > > 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. > > > On Mon, Jun 4, 2018, 7:42 AM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > > > Le lun. 4 juin 2018 à 13:36, John D. Ament <johndam...@apache.org> a écrit : > 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? > > > On Mon, Jun 4, 2018, 3:57 AM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > Well b doesn't solve 3, any way we get karma to do the releases? This would > solve that neatly. > > Romain Manni-Bucau > @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book > > > Le lun. 4 juin 2018 à 09:52, Mark Struberg <strub...@yahoo.de> a écrit : > 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 > > LieGrue, > strub > > > Am 04.06.2018 um 09:09 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: > > > > 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 >
