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