Le lun. 4 juin 2018 à 13:36, John D. Ament <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 < >>> [email protected]>: >>> > >>> > 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 >>> >>>
