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.
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 >> >>
