git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DISCUSS] Do we want to host MP-api versions or not


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 BlogGithub | LinkedIn | Book


Le lun. 4 juin 2018 à 09:52, Mark Struberg <struberg@xxxxxxxx> 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 <rmannibucau@xxxxxxxxx>:
>
> 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