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?
And the issue with Java 9 is that you can end up with multiple copies of the packages. 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 <https://twitter.com/rmannibucau> | Blog >>> <https://rmannibucau.metawerx.net/> | Old Blog >>> <http://rmannibucau.wordpress.com> | Github >>> <https://github.com/rmannibucau> | LinkedIn >>> <https://www.linkedin.com/in/rmannibucau> | Book >>> <https://www.packtpub.com/application-development/java-ee-8-high-performance> >>> >>> >>> 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 >>>> >>>>
