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

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Romain Manni-Bucau
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 BlogGithub | LinkedIn | Book
Reply | Threaded
Open this post in threaded view
|

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

Mark Struberg
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 <[hidden email]>:
>
> 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

Reply | Threaded
Open this post in threaded view
|

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

Romain Manni-Bucau
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 <[hidden email]> 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 <[hidden email]>:
>
> 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

Reply | Threaded
Open this post in threaded view
|

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

John D. Ament
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 <[hidden email]> 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 |  Blog | Old BlogGithub | LinkedIn | Book


Le lun. 4 juin 2018 à 09:52, Mark Struberg <[hidden email]> 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 <[hidden email]>:
>
> 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

Reply | Threaded
Open this post in threaded view
|

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

Romain Manni-Bucau


Le lun. 4 juin 2018 à 13:36, John D. Ament <[hidden email]> 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 <[hidden email]> 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 |  Blog | Old BlogGithub | LinkedIn | Book


Le lun. 4 juin 2018 à 09:52, Mark Struberg <[hidden email]> 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 <[hidden email]>:
>
> 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

Reply | Threaded
Open this post in threaded view
|

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

John D. Ament
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 <[hidden email]> wrote:


Le lun. 4 juin 2018 à 13:36, John D. Ament <[hidden email]> 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 <[hidden email]> 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 |  Blog | Old BlogGithub | LinkedIn | Book


Le lun. 4 juin 2018 à 09:52, Mark Struberg <[hidden email]> 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 <[hidden email]>:
>
> 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

Reply | Threaded
Open this post in threaded view
|

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

Romain Manni-Bucau


Le lun. 4 juin 2018 à 13:45, John D. Ament <[hidden email]> a écrit :
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?

Nop, liberty does it all wrong. They force setGlobalProvider in the API and this is not needed as any geronimo spec jar or aries shows. This leads to an unsafe user accessible API which is not thread safe and a server destructor :(.
We need https://github.com/apache/geronimo-specs/pull/9 and at least SPI-Provider header, spifly can be nice too - is used today.
 

And the issue with Java 9 is that you can end up with multiple copies of the packages.

This is not really an issue, no more than today actually since it is the same ones with the same content.
 

On Mon, Jun 4, 2018, 7:42 AM Romain Manni-Bucau <[hidden email]> wrote:


Le lun. 4 juin 2018 à 13:36, John D. Ament <[hidden email]> 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 <[hidden email]> 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 |  Blog | Old BlogGithub | LinkedIn | Book


Le lun. 4 juin 2018 à 09:52, Mark Struberg <[hidden email]> 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 <[hidden email]>:
>
> 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

Reply | Threaded
Open this post in threaded view
|

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

Mark Struberg
In reply to this post by Romain Manni-Bucau
Btw, I DO have karma to do releases in microprofile ;)

LieGrue,
strub


> Am 04.06.2018 um 09:57 schrieb Romain Manni-Bucau <[hidden email]>:
>
> 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 Blog | Github | LinkedIn | Book
>
>
> Le lun. 4 juin 2018 à 09:52, Mark Struberg <[hidden email]> 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 <[hidden email]>:
> >
> > 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
>

Reply | Threaded
Open this post in threaded view
|

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

Mark Struberg
In reply to this post by Romain Manni-Bucau
I'm with Romain on this one. There is a ticket open for various MP specs.
We should evaluate this and then push for it to be fixed.

LieGrue,
strub


> Am 04.06.2018 um 15:09 schrieb Romain Manni-Bucau <[hidden email]>:
>
>
>
> Le lun. 4 juin 2018 à 13:45, John D. Ament <[hidden email]> a écrit :
> 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?
>
> Nop, liberty does it all wrong. They force setGlobalProvider in the API and this is not needed as any geronimo spec jar or aries shows. This leads to an unsafe user accessible API which is not thread safe and a server destructor :(.
> We need https://github.com/apache/geronimo-specs/pull/9 and at least SPI-Provider header, spifly can be nice too - is used today.
>  
>
> And the issue with Java 9 is that you can end up with multiple copies of the packages.
>
> This is not really an issue, no more than today actually since it is the same ones with the same content.
>  
>
> On Mon, Jun 4, 2018, 7:42 AM Romain Manni-Bucau <[hidden email]> wrote:
>
>
> Le lun. 4 juin 2018 à 13:36, John D. Ament <[hidden email]> 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 <[hidden email]> 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 |  Blog | Old Blog | Github | LinkedIn | Book
>
>
> Le lun. 4 juin 2018 à 09:52, Mark Struberg <[hidden email]> 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 <[hidden email]>:
> >
> > 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
>

Reply | Threaded
Open this post in threaded view
|

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

Mark Struberg
Just to get this down to paper somehow.
The following is a list of specs I'd going to release:

Sending        geronimo-activation_1.1_spec/pom.xml
Sending        geronimo-annotation_1.2_spec/pom.xml
Sending        geronimo-annotation_1.3_spec/pom.xml
Sending        geronimo-atinject_1.0_spec/pom.xml
Sending        geronimo-availability_1.0_spec/pom.xml
Sending        geronimo-concurrent_1.0_spec/pom.xml
Sending        geronimo-ejb_3.1_spec/pom.xml
Sending        geronimo-ejb_3.2_spec/pom.xml
Sending        geronimo-el_2.2_spec/pom.xml
Sending        geronimo-interceptor_1.1_spec/pom.xml
Sending        geronimo-interceptor_1.2_spec/pom.xml
Sending        geronimo-j2ee-connector_1.6_spec/pom.xml
Sending        geronimo-jacc_1.1_spec/pom.xml
Sending        geronimo-jacc_1.4_spec/pom.xml
Sending        geronimo-jaspic_1.0_spec/pom.xml
Sending        geronimo-javamail_1.4_spec/pom.xml
Sending        geronimo-javamail_1.5_spec/pom.xml
Sending        geronimo-jaxb_2.0_spec/pom.xml
Sending        geronimo-jaxb_2.1_spec/pom.xml
Sending        geronimo-jaxb_2.2_spec/pom.xml
Sending        geronimo-jaxr_1.0_spec/pom.xml
Sending        geronimo-jaxrpc_1.1_spec/pom.xml
Sending        geronimo-jaxrs_1.1_spec/pom.xml
Sending        geronimo-jaxrs_2.0_spec/pom.xml
Sending        geronimo-jaxrs_2.1_spec/pom.xml
Sending        geronimo-jaxws_2.1.1_spec/pom.xml
Sending        geronimo-jaxws_2.1_spec/pom.xml
Sending        geronimo-jaxws_2.2_spec/pom.xml
Sending        geronimo-jbatch_1.0_spec/pom.xml
Sending        geronimo-jcache_1.0_spec/pom.xml
Sending        geronimo-jcdi_1.0_spec/pom.xml
Sending        geronimo-jcdi_1.1_spec/pom.xml
Sending        geronimo-jcdi_2.0_spec/pom.xml
Sending        geronimo-jms_1.1_spec/pom.xml
Sending        geronimo-jms_2.0_spec/pom.xml
Sending        geronimo-jpa_1.0_spec/pom.xml
Sending        geronimo-jpa_2.0_spec/pom.xml
Sending        geronimo-jpa_2.1_spec/pom.xml
Sending        geronimo-json_1.0_spec/pom.xml
Sending        geronimo-json_1.1_spec/pom.xml
Sending        geronimo-jsonb_1.0_spec/pom.xml
Sending        geronimo-jsp_2.1_spec/pom.xml
Sending        geronimo-jsp_2.2_spec/pom.xml
Sending        geronimo-jta_1.1_spec/pom.xml
Sending        geronimo-jta_1.2_spec/pom.xml
Sending        geronimo-osgi-support/geronimo-osgi-itesta/pom.xml
Sending        geronimo-osgi-support/geronimo-osgi-itestb/pom.xml
Sending        geronimo-osgi-support/geronimo-osgi-locator/pom.xml
Sending        geronimo-osgi-support/geronimo-osgi-registry/pom.xml
Sending        geronimo-osgi-support/pom.xml
Sending        geronimo-saaj_1.3_spec/pom.xml
Sending        geronimo-servlet_2.5_spec/pom.xml
Sending        geronimo-servlet_3.0_spec/pom.xml
Sending        geronimo-servlet_3.1_spec/pom.xml
Sending        geronimo-stax-api_1.0_spec/pom.xml
Sending        geronimo-stax-api_1.2_spec/pom.xml
Sending        geronimo-validation_1.0_spec/pom.xml
Sending        geronimo-validation_1.1_spec/pom.xml
Sending        geronimo-validation_2.0_spec/pom.xml
Sending        geronimo-websockets_1.0_spec/pom.xml
Sending        geronimo-ws-metadata_2.0_spec/pom.xml


I've removed ancient specs which are not maintained anymore like the Client Profile.

Do we also want to pimp the flava projects? Should I release those as well?
The natural order would be to release all the osgi base stuff in one go, then take on a few other specs in bigger bundles until the whole list is worked off.

LieGrue,
strub

> Am 04.06.2018 um 16:36 schrieb Mark Struberg <[hidden email]>:
>
> I'm with Romain on this one. There is a ticket open for various MP specs.
> We should evaluate this and then push for it to be fixed.
>
> LieGrue,
> strub
>
>
>> Am 04.06.2018 um 15:09 schrieb Romain Manni-Bucau <[hidden email]>:
>>
>>
>>
>> Le lun. 4 juin 2018 à 13:45, John D. Ament <[hidden email]> a écrit :
>> 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?
>>
>> Nop, liberty does it all wrong. They force setGlobalProvider in the API and this is not needed as any geronimo spec jar or aries shows. This leads to an unsafe user accessible API which is not thread safe and a server destructor :(.
>> We need https://github.com/apache/geronimo-specs/pull/9 and at least SPI-Provider header, spifly can be nice too - is used today.
>>
>>
>> And the issue with Java 9 is that you can end up with multiple copies of the packages.
>>
>> This is not really an issue, no more than today actually since it is the same ones with the same content.
>>
>>
>> On Mon, Jun 4, 2018, 7:42 AM Romain Manni-Bucau <[hidden email]> wrote:
>>
>>
>> Le lun. 4 juin 2018 à 13:36, John D. Ament <[hidden email]> 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 <[hidden email]> 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 |  Blog | Old Blog | Github | LinkedIn | Book
>>
>>
>> Le lun. 4 juin 2018 à 09:52, Mark Struberg <[hidden email]> 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 <[hidden email]>:
>>>
>>> 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
>>
>

Reply | Threaded
Open this post in threaded view
|

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

Romain Manni-Bucau
Don't recall but do we need flava anymore?

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le lun. 4 juin 2018 à 18:09, Mark Struberg <[hidden email]> a écrit :
Just to get this down to paper somehow.
The following is a list of specs I'd going to release:

Sending        geronimo-activation_1.1_spec/pom.xml
Sending        geronimo-annotation_1.2_spec/pom.xml
Sending        geronimo-annotation_1.3_spec/pom.xml
Sending        geronimo-atinject_1.0_spec/pom.xml
Sending        geronimo-availability_1.0_spec/pom.xml
Sending        geronimo-concurrent_1.0_spec/pom.xml
Sending        geronimo-ejb_3.1_spec/pom.xml
Sending        geronimo-ejb_3.2_spec/pom.xml
Sending        geronimo-el_2.2_spec/pom.xml
Sending        geronimo-interceptor_1.1_spec/pom.xml
Sending        geronimo-interceptor_1.2_spec/pom.xml
Sending        geronimo-j2ee-connector_1.6_spec/pom.xml
Sending        geronimo-jacc_1.1_spec/pom.xml
Sending        geronimo-jacc_1.4_spec/pom.xml
Sending        geronimo-jaspic_1.0_spec/pom.xml
Sending        geronimo-javamail_1.4_spec/pom.xml
Sending        geronimo-javamail_1.5_spec/pom.xml
Sending        geronimo-jaxb_2.0_spec/pom.xml
Sending        geronimo-jaxb_2.1_spec/pom.xml
Sending        geronimo-jaxb_2.2_spec/pom.xml
Sending        geronimo-jaxr_1.0_spec/pom.xml
Sending        geronimo-jaxrpc_1.1_spec/pom.xml
Sending        geronimo-jaxrs_1.1_spec/pom.xml
Sending        geronimo-jaxrs_2.0_spec/pom.xml
Sending        geronimo-jaxrs_2.1_spec/pom.xml
Sending        geronimo-jaxws_2.1.1_spec/pom.xml
Sending        geronimo-jaxws_2.1_spec/pom.xml
Sending        geronimo-jaxws_2.2_spec/pom.xml
Sending        geronimo-jbatch_1.0_spec/pom.xml
Sending        geronimo-jcache_1.0_spec/pom.xml
Sending        geronimo-jcdi_1.0_spec/pom.xml
Sending        geronimo-jcdi_1.1_spec/pom.xml
Sending        geronimo-jcdi_2.0_spec/pom.xml
Sending        geronimo-jms_1.1_spec/pom.xml
Sending        geronimo-jms_2.0_spec/pom.xml
Sending        geronimo-jpa_1.0_spec/pom.xml
Sending        geronimo-jpa_2.0_spec/pom.xml
Sending        geronimo-jpa_2.1_spec/pom.xml
Sending        geronimo-json_1.0_spec/pom.xml
Sending        geronimo-json_1.1_spec/pom.xml
Sending        geronimo-jsonb_1.0_spec/pom.xml
Sending        geronimo-jsp_2.1_spec/pom.xml
Sending        geronimo-jsp_2.2_spec/pom.xml
Sending        geronimo-jta_1.1_spec/pom.xml
Sending        geronimo-jta_1.2_spec/pom.xml
Sending        geronimo-osgi-support/geronimo-osgi-itesta/pom.xml
Sending        geronimo-osgi-support/geronimo-osgi-itestb/pom.xml
Sending        geronimo-osgi-support/geronimo-osgi-locator/pom.xml
Sending        geronimo-osgi-support/geronimo-osgi-registry/pom.xml
Sending        geronimo-osgi-support/pom.xml
Sending        geronimo-saaj_1.3_spec/pom.xml
Sending        geronimo-servlet_2.5_spec/pom.xml
Sending        geronimo-servlet_3.0_spec/pom.xml
Sending        geronimo-servlet_3.1_spec/pom.xml
Sending        geronimo-stax-api_1.0_spec/pom.xml
Sending        geronimo-stax-api_1.2_spec/pom.xml
Sending        geronimo-validation_1.0_spec/pom.xml
Sending        geronimo-validation_1.1_spec/pom.xml
Sending        geronimo-validation_2.0_spec/pom.xml
Sending        geronimo-websockets_1.0_spec/pom.xml
Sending        geronimo-ws-metadata_2.0_spec/pom.xml


I've removed ancient specs which are not maintained anymore like the Client Profile.

Do we also want to pimp the flava projects? Should I release those as well?
The natural order would be to release all the osgi base stuff in one go, then take on a few other specs in bigger bundles until the whole list is worked off.

LieGrue,
strub

> Am 04.06.2018 um 16:36 schrieb Mark Struberg <[hidden email]>:
>
> I'm with Romain on this one. There is a ticket open for various MP specs.
> We should evaluate this and then push for it to be fixed.
>
> LieGrue,
> strub
>
>
>> Am 04.06.2018 um 15:09 schrieb Romain Manni-Bucau <[hidden email]>:
>>
>>
>>
>> Le lun. 4 juin 2018 à 13:45, John D. Ament <[hidden email]> a écrit :
>> 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?
>>
>> Nop, liberty does it all wrong. They force setGlobalProvider in the API and this is not needed as any geronimo spec jar or aries shows. This leads to an unsafe user accessible API which is not thread safe and a server destructor :(.
>> We need https://github.com/apache/geronimo-specs/pull/9 and at least SPI-Provider header, spifly can be nice too - is used today.
>>
>>
>> And the issue with Java 9 is that you can end up with multiple copies of the packages.
>>
>> This is not really an issue, no more than today actually since it is the same ones with the same content.
>>
>>
>> On Mon, Jun 4, 2018, 7:42 AM Romain Manni-Bucau <[hidden email]> wrote:
>>
>>
>> Le lun. 4 juin 2018 à 13:36, John D. Ament <[hidden email]> 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 <[hidden email]> 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 |  Blog | Old Blog | Github | LinkedIn | Book
>>
>>
>> Le lun. 4 juin 2018 à 09:52, Mark Struberg <[hidden email]> 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 <[hidden email]>:
>>>
>>> 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
>>
>

Reply | Threaded
Open this post in threaded view
|

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

Mark Struberg
yes, they are the parents for the various g projects.

flava5 is for java5 projects, flava6 for java6,....

LieGrue,
strub


> Am 04.06.2018 um 18:15 schrieb Romain Manni-Bucau <[hidden email]>:
>
> Don't recall but do we need flava anymore?
>
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>
>
> Le lun. 4 juin 2018 à 18:09, Mark Struberg <[hidden email]> a écrit :
> Just to get this down to paper somehow.
> The following is a list of specs I'd going to release:
>
> Sending        geronimo-activation_1.1_spec/pom.xml
> Sending        geronimo-annotation_1.2_spec/pom.xml
> Sending        geronimo-annotation_1.3_spec/pom.xml
> Sending        geronimo-atinject_1.0_spec/pom.xml
> Sending        geronimo-availability_1.0_spec/pom.xml
> Sending        geronimo-concurrent_1.0_spec/pom.xml
> Sending        geronimo-ejb_3.1_spec/pom.xml
> Sending        geronimo-ejb_3.2_spec/pom.xml
> Sending        geronimo-el_2.2_spec/pom.xml
> Sending        geronimo-interceptor_1.1_spec/pom.xml
> Sending        geronimo-interceptor_1.2_spec/pom.xml
> Sending        geronimo-j2ee-connector_1.6_spec/pom.xml
> Sending        geronimo-jacc_1.1_spec/pom.xml
> Sending        geronimo-jacc_1.4_spec/pom.xml
> Sending        geronimo-jaspic_1.0_spec/pom.xml
> Sending        geronimo-javamail_1.4_spec/pom.xml
> Sending        geronimo-javamail_1.5_spec/pom.xml
> Sending        geronimo-jaxb_2.0_spec/pom.xml
> Sending        geronimo-jaxb_2.1_spec/pom.xml
> Sending        geronimo-jaxb_2.2_spec/pom.xml
> Sending        geronimo-jaxr_1.0_spec/pom.xml
> Sending        geronimo-jaxrpc_1.1_spec/pom.xml
> Sending        geronimo-jaxrs_1.1_spec/pom.xml
> Sending        geronimo-jaxrs_2.0_spec/pom.xml
> Sending        geronimo-jaxrs_2.1_spec/pom.xml
> Sending        geronimo-jaxws_2.1.1_spec/pom.xml
> Sending        geronimo-jaxws_2.1_spec/pom.xml
> Sending        geronimo-jaxws_2.2_spec/pom.xml
> Sending        geronimo-jbatch_1.0_spec/pom.xml
> Sending        geronimo-jcache_1.0_spec/pom.xml
> Sending        geronimo-jcdi_1.0_spec/pom.xml
> Sending        geronimo-jcdi_1.1_spec/pom.xml
> Sending        geronimo-jcdi_2.0_spec/pom.xml
> Sending        geronimo-jms_1.1_spec/pom.xml
> Sending        geronimo-jms_2.0_spec/pom.xml
> Sending        geronimo-jpa_1.0_spec/pom.xml
> Sending        geronimo-jpa_2.0_spec/pom.xml
> Sending        geronimo-jpa_2.1_spec/pom.xml
> Sending        geronimo-json_1.0_spec/pom.xml
> Sending        geronimo-json_1.1_spec/pom.xml
> Sending        geronimo-jsonb_1.0_spec/pom.xml
> Sending        geronimo-jsp_2.1_spec/pom.xml
> Sending        geronimo-jsp_2.2_spec/pom.xml
> Sending        geronimo-jta_1.1_spec/pom.xml
> Sending        geronimo-jta_1.2_spec/pom.xml
> Sending        geronimo-osgi-support/geronimo-osgi-itesta/pom.xml
> Sending        geronimo-osgi-support/geronimo-osgi-itestb/pom.xml
> Sending        geronimo-osgi-support/geronimo-osgi-locator/pom.xml
> Sending        geronimo-osgi-support/geronimo-osgi-registry/pom.xml
> Sending        geronimo-osgi-support/pom.xml
> Sending        geronimo-saaj_1.3_spec/pom.xml
> Sending        geronimo-servlet_2.5_spec/pom.xml
> Sending        geronimo-servlet_3.0_spec/pom.xml
> Sending        geronimo-servlet_3.1_spec/pom.xml
> Sending        geronimo-stax-api_1.0_spec/pom.xml
> Sending        geronimo-stax-api_1.2_spec/pom.xml
> Sending        geronimo-validation_1.0_spec/pom.xml
> Sending        geronimo-validation_1.1_spec/pom.xml
> Sending        geronimo-validation_2.0_spec/pom.xml
> Sending        geronimo-websockets_1.0_spec/pom.xml
> Sending        geronimo-ws-metadata_2.0_spec/pom.xml
>
>
> I've removed ancient specs which are not maintained anymore like the Client Profile.
>
> Do we also want to pimp the flava projects? Should I release those as well?
> The natural order would be to release all the osgi base stuff in one go, then take on a few other specs in bigger bundles until the whole list is worked off.
>
> LieGrue,
> strub
>
> > Am 04.06.2018 um 16:36 schrieb Mark Struberg <[hidden email]>:
> >
> > I'm with Romain on this one. There is a ticket open for various MP specs.
> > We should evaluate this and then push for it to be fixed.
> >
> > LieGrue,
> > strub
> >
> >
> >> Am 04.06.2018 um 15:09 schrieb Romain Manni-Bucau <[hidden email]>:
> >>
> >>
> >>
> >> Le lun. 4 juin 2018 à 13:45, John D. Ament <[hidden email]> a écrit :
> >> 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?
> >>
> >> Nop, liberty does it all wrong. They force setGlobalProvider in the API and this is not needed as any geronimo spec jar or aries shows. This leads to an unsafe user accessible API which is not thread safe and a server destructor :(.
> >> We need https://github.com/apache/geronimo-specs/pull/9 and at least SPI-Provider header, spifly can be nice too - is used today.
> >>
> >>
> >> And the issue with Java 9 is that you can end up with multiple copies of the packages.
> >>
> >> This is not really an issue, no more than today actually since it is the same ones with the same content.
> >>
> >>
> >> On Mon, Jun 4, 2018, 7:42 AM Romain Manni-Bucau <[hidden email]> wrote:
> >>
> >>
> >> Le lun. 4 juin 2018 à 13:36, John D. Ament <[hidden email]> 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 <[hidden email]> 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 |  Blog | Old Blog | Github | LinkedIn | Book
> >>
> >>
> >> Le lun. 4 juin 2018 à 09:52, Mark Struberg <[hidden email]> 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 <[hidden email]>:
> >>>
> >>> 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
> >>
> >
>

Reply | Threaded
Open this post in threaded view
|

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

Romain Manni-Bucau
I know that part but never understood why not using apache parent

Le lun. 4 juin 2018 22:06, Mark Struberg <[hidden email]> a écrit :
yes, they are the parents for the various g projects.

flava5 is for java5 projects, flava6 for java6,....

LieGrue,
strub


> Am 04.06.2018 um 18:15 schrieb Romain Manni-Bucau <[hidden email]>:
>
> Don't recall but do we need flava anymore?
>
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>
>
> Le lun. 4 juin 2018 à 18:09, Mark Struberg <[hidden email]> a écrit :
> Just to get this down to paper somehow.
> The following is a list of specs I'd going to release:
>
> Sending        geronimo-activation_1.1_spec/pom.xml
> Sending        geronimo-annotation_1.2_spec/pom.xml
> Sending        geronimo-annotation_1.3_spec/pom.xml
> Sending        geronimo-atinject_1.0_spec/pom.xml
> Sending        geronimo-availability_1.0_spec/pom.xml
> Sending        geronimo-concurrent_1.0_spec/pom.xml
> Sending        geronimo-ejb_3.1_spec/pom.xml
> Sending        geronimo-ejb_3.2_spec/pom.xml
> Sending        geronimo-el_2.2_spec/pom.xml
> Sending        geronimo-interceptor_1.1_spec/pom.xml
> Sending        geronimo-interceptor_1.2_spec/pom.xml
> Sending        geronimo-j2ee-connector_1.6_spec/pom.xml
> Sending        geronimo-jacc_1.1_spec/pom.xml
> Sending        geronimo-jacc_1.4_spec/pom.xml
> Sending        geronimo-jaspic_1.0_spec/pom.xml
> Sending        geronimo-javamail_1.4_spec/pom.xml
> Sending        geronimo-javamail_1.5_spec/pom.xml
> Sending        geronimo-jaxb_2.0_spec/pom.xml
> Sending        geronimo-jaxb_2.1_spec/pom.xml
> Sending        geronimo-jaxb_2.2_spec/pom.xml
> Sending        geronimo-jaxr_1.0_spec/pom.xml
> Sending        geronimo-jaxrpc_1.1_spec/pom.xml
> Sending        geronimo-jaxrs_1.1_spec/pom.xml
> Sending        geronimo-jaxrs_2.0_spec/pom.xml
> Sending        geronimo-jaxrs_2.1_spec/pom.xml
> Sending        geronimo-jaxws_2.1.1_spec/pom.xml
> Sending        geronimo-jaxws_2.1_spec/pom.xml
> Sending        geronimo-jaxws_2.2_spec/pom.xml
> Sending        geronimo-jbatch_1.0_spec/pom.xml
> Sending        geronimo-jcache_1.0_spec/pom.xml
> Sending        geronimo-jcdi_1.0_spec/pom.xml
> Sending        geronimo-jcdi_1.1_spec/pom.xml
> Sending        geronimo-jcdi_2.0_spec/pom.xml
> Sending        geronimo-jms_1.1_spec/pom.xml
> Sending        geronimo-jms_2.0_spec/pom.xml
> Sending        geronimo-jpa_1.0_spec/pom.xml
> Sending        geronimo-jpa_2.0_spec/pom.xml
> Sending        geronimo-jpa_2.1_spec/pom.xml
> Sending        geronimo-json_1.0_spec/pom.xml
> Sending        geronimo-json_1.1_spec/pom.xml
> Sending        geronimo-jsonb_1.0_spec/pom.xml
> Sending        geronimo-jsp_2.1_spec/pom.xml
> Sending        geronimo-jsp_2.2_spec/pom.xml
> Sending        geronimo-jta_1.1_spec/pom.xml
> Sending        geronimo-jta_1.2_spec/pom.xml
> Sending        geronimo-osgi-support/geronimo-osgi-itesta/pom.xml
> Sending        geronimo-osgi-support/geronimo-osgi-itestb/pom.xml
> Sending        geronimo-osgi-support/geronimo-osgi-locator/pom.xml
> Sending        geronimo-osgi-support/geronimo-osgi-registry/pom.xml
> Sending        geronimo-osgi-support/pom.xml
> Sending        geronimo-saaj_1.3_spec/pom.xml
> Sending        geronimo-servlet_2.5_spec/pom.xml
> Sending        geronimo-servlet_3.0_spec/pom.xml
> Sending        geronimo-servlet_3.1_spec/pom.xml
> Sending        geronimo-stax-api_1.0_spec/pom.xml
> Sending        geronimo-stax-api_1.2_spec/pom.xml
> Sending        geronimo-validation_1.0_spec/pom.xml
> Sending        geronimo-validation_1.1_spec/pom.xml
> Sending        geronimo-validation_2.0_spec/pom.xml
> Sending        geronimo-websockets_1.0_spec/pom.xml
> Sending        geronimo-ws-metadata_2.0_spec/pom.xml
>
>
> I've removed ancient specs which are not maintained anymore like the Client Profile.
>
> Do we also want to pimp the flava projects? Should I release those as well?
> The natural order would be to release all the osgi base stuff in one go, then take on a few other specs in bigger bundles until the whole list is worked off.
>
> LieGrue,
> strub
>
> > Am 04.06.2018 um 16:36 schrieb Mark Struberg <[hidden email]>:
> >
> > I'm with Romain on this one. There is a ticket open for various MP specs.
> > We should evaluate this and then push for it to be fixed.
> >
> > LieGrue,
> > strub
> >
> >
> >> Am 04.06.2018 um 15:09 schrieb Romain Manni-Bucau <[hidden email]>:
> >>
> >>
> >>
> >> Le lun. 4 juin 2018 à 13:45, John D. Ament <[hidden email]> a écrit :
> >> 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?
> >>
> >> Nop, liberty does it all wrong. They force setGlobalProvider in the API and this is not needed as any geronimo spec jar or aries shows. This leads to an unsafe user accessible API which is not thread safe and a server destructor :(.
> >> We need https://github.com/apache/geronimo-specs/pull/9 and at least SPI-Provider header, spifly can be nice too - is used today.
> >>
> >>
> >> And the issue with Java 9 is that you can end up with multiple copies of the packages.
> >>
> >> This is not really an issue, no more than today actually since it is the same ones with the same content.
> >>
> >>
> >> On Mon, Jun 4, 2018, 7:42 AM Romain Manni-Bucau <[hidden email]> wrote:
> >>
> >>
> >> Le lun. 4 juin 2018 à 13:36, John D. Ament <[hidden email]> 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 <[hidden email]> 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 |  Blog | Old Blog | Github | LinkedIn | Book
> >>
> >>
> >> Le lun. 4 juin 2018 à 09:52, Mark Struberg <[hidden email]> 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 <[hidden email]>:
> >>>
> >>> 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
> >>
> >
>

Reply | Threaded
Open this post in threaded view
|

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

Mark Struberg
It contains a few standard plugin settings, but that's really it.

LieGrue,
strub
 

> Am 05.06.2018 um 06:52 schrieb Romain Manni-Bucau <[hidden email]>:
>
> I know that part but never understood why not using apache parent
>
> Le lun. 4 juin 2018 22:06, Mark Struberg <[hidden email]> a écrit :
> yes, they are the parents for the various g projects.
>
> flava5 is for java5 projects, flava6 for java6,....
>
> LieGrue,
> strub
>
>
> > Am 04.06.2018 um 18:15 schrieb Romain Manni-Bucau <[hidden email]>:
> >
> > Don't recall but do we need flava anymore?
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> >
> >
> > Le lun. 4 juin 2018 à 18:09, Mark Struberg <[hidden email]> a écrit :
> > Just to get this down to paper somehow.
> > The following is a list of specs I'd going to release:
> >
> > Sending        geronimo-activation_1.1_spec/pom.xml
> > Sending        geronimo-annotation_1.2_spec/pom.xml
> > Sending        geronimo-annotation_1.3_spec/pom.xml
> > Sending        geronimo-atinject_1.0_spec/pom.xml
> > Sending        geronimo-availability_1.0_spec/pom.xml
> > Sending        geronimo-concurrent_1.0_spec/pom.xml
> > Sending        geronimo-ejb_3.1_spec/pom.xml
> > Sending        geronimo-ejb_3.2_spec/pom.xml
> > Sending        geronimo-el_2.2_spec/pom.xml
> > Sending        geronimo-interceptor_1.1_spec/pom.xml
> > Sending        geronimo-interceptor_1.2_spec/pom.xml
> > Sending        geronimo-j2ee-connector_1.6_spec/pom.xml
> > Sending        geronimo-jacc_1.1_spec/pom.xml
> > Sending        geronimo-jacc_1.4_spec/pom.xml
> > Sending        geronimo-jaspic_1.0_spec/pom.xml
> > Sending        geronimo-javamail_1.4_spec/pom.xml
> > Sending        geronimo-javamail_1.5_spec/pom.xml
> > Sending        geronimo-jaxb_2.0_spec/pom.xml
> > Sending        geronimo-jaxb_2.1_spec/pom.xml
> > Sending        geronimo-jaxb_2.2_spec/pom.xml
> > Sending        geronimo-jaxr_1.0_spec/pom.xml
> > Sending        geronimo-jaxrpc_1.1_spec/pom.xml
> > Sending        geronimo-jaxrs_1.1_spec/pom.xml
> > Sending        geronimo-jaxrs_2.0_spec/pom.xml
> > Sending        geronimo-jaxrs_2.1_spec/pom.xml
> > Sending        geronimo-jaxws_2.1.1_spec/pom.xml
> > Sending        geronimo-jaxws_2.1_spec/pom.xml
> > Sending        geronimo-jaxws_2.2_spec/pom.xml
> > Sending        geronimo-jbatch_1.0_spec/pom.xml
> > Sending        geronimo-jcache_1.0_spec/pom.xml
> > Sending        geronimo-jcdi_1.0_spec/pom.xml
> > Sending        geronimo-jcdi_1.1_spec/pom.xml
> > Sending        geronimo-jcdi_2.0_spec/pom.xml
> > Sending        geronimo-jms_1.1_spec/pom.xml
> > Sending        geronimo-jms_2.0_spec/pom.xml
> > Sending        geronimo-jpa_1.0_spec/pom.xml
> > Sending        geronimo-jpa_2.0_spec/pom.xml
> > Sending        geronimo-jpa_2.1_spec/pom.xml
> > Sending        geronimo-json_1.0_spec/pom.xml
> > Sending        geronimo-json_1.1_spec/pom.xml
> > Sending        geronimo-jsonb_1.0_spec/pom.xml
> > Sending        geronimo-jsp_2.1_spec/pom.xml
> > Sending        geronimo-jsp_2.2_spec/pom.xml
> > Sending        geronimo-jta_1.1_spec/pom.xml
> > Sending        geronimo-jta_1.2_spec/pom.xml
> > Sending        geronimo-osgi-support/geronimo-osgi-itesta/pom.xml
> > Sending        geronimo-osgi-support/geronimo-osgi-itestb/pom.xml
> > Sending        geronimo-osgi-support/geronimo-osgi-locator/pom.xml
> > Sending        geronimo-osgi-support/geronimo-osgi-registry/pom.xml
> > Sending        geronimo-osgi-support/pom.xml
> > Sending        geronimo-saaj_1.3_spec/pom.xml
> > Sending        geronimo-servlet_2.5_spec/pom.xml
> > Sending        geronimo-servlet_3.0_spec/pom.xml
> > Sending        geronimo-servlet_3.1_spec/pom.xml
> > Sending        geronimo-stax-api_1.0_spec/pom.xml
> > Sending        geronimo-stax-api_1.2_spec/pom.xml
> > Sending        geronimo-validation_1.0_spec/pom.xml
> > Sending        geronimo-validation_1.1_spec/pom.xml
> > Sending        geronimo-validation_2.0_spec/pom.xml
> > Sending        geronimo-websockets_1.0_spec/pom.xml
> > Sending        geronimo-ws-metadata_2.0_spec/pom.xml
> >
> >
> > I've removed ancient specs which are not maintained anymore like the Client Profile.
> >
> > Do we also want to pimp the flava projects? Should I release those as well?
> > The natural order would be to release all the osgi base stuff in one go, then take on a few other specs in bigger bundles until the whole list is worked off.
> >
> > LieGrue,
> > strub
> >
> > > Am 04.06.2018 um 16:36 schrieb Mark Struberg <[hidden email]>:
> > >
> > > I'm with Romain on this one. There is a ticket open for various MP specs.
> > > We should evaluate this and then push for it to be fixed.
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > >> Am 04.06.2018 um 15:09 schrieb Romain Manni-Bucau <[hidden email]>:
> > >>
> > >>
> > >>
> > >> Le lun. 4 juin 2018 à 13:45, John D. Ament <[hidden email]> a écrit :
> > >> 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?
> > >>
> > >> Nop, liberty does it all wrong. They force setGlobalProvider in the API and this is not needed as any geronimo spec jar or aries shows. This leads to an unsafe user accessible API which is not thread safe and a server destructor :(.
> > >> We need https://github.com/apache/geronimo-specs/pull/9 and at least SPI-Provider header, spifly can be nice too - is used today.
> > >>
> > >>
> > >> And the issue with Java 9 is that you can end up with multiple copies of the packages.
> > >>
> > >> This is not really an issue, no more than today actually since it is the same ones with the same content.
> > >>
> > >>
> > >> On Mon, Jun 4, 2018, 7:42 AM Romain Manni-Bucau <[hidden email]> wrote:
> > >>
> > >>
> > >> Le lun. 4 juin 2018 à 13:36, John D. Ament <[hidden email]> 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 <[hidden email]> 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 |  Blog | Old Blog | Github | LinkedIn | Book
> > >>
> > >>
> > >> Le lun. 4 juin 2018 à 09:52, Mark Struberg <[hidden email]> 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 <[hidden email]>:
> > >>>
> > >>> 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
> > >>
> > >
> >
>

Reply | Threaded
Open this post in threaded view
|

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

Romain Manni-Bucau
So not needed if we use apache parent pby - this was my point

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le mar. 5 juin 2018 à 08:41, Mark Struberg <[hidden email]> a écrit :
It contains a few standard plugin settings, but that's really it.

LieGrue,
strub


> Am 05.06.2018 um 06:52 schrieb Romain Manni-Bucau <[hidden email]>:
>
> I know that part but never understood why not using apache parent
>
> Le lun. 4 juin 2018 22:06, Mark Struberg <[hidden email]> a écrit :
> yes, they are the parents for the various g projects.
>
> flava5 is for java5 projects, flava6 for java6,....
>
> LieGrue,
> strub
>
>
> > Am 04.06.2018 um 18:15 schrieb Romain Manni-Bucau <[hidden email]>:
> >
> > Don't recall but do we need flava anymore?
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> >
> >
> > Le lun. 4 juin 2018 à 18:09, Mark Struberg <[hidden email]> a écrit :
> > Just to get this down to paper somehow.
> > The following is a list of specs I'd going to release:
> >
> > Sending        geronimo-activation_1.1_spec/pom.xml
> > Sending        geronimo-annotation_1.2_spec/pom.xml
> > Sending        geronimo-annotation_1.3_spec/pom.xml
> > Sending        geronimo-atinject_1.0_spec/pom.xml
> > Sending        geronimo-availability_1.0_spec/pom.xml
> > Sending        geronimo-concurrent_1.0_spec/pom.xml
> > Sending        geronimo-ejb_3.1_spec/pom.xml
> > Sending        geronimo-ejb_3.2_spec/pom.xml
> > Sending        geronimo-el_2.2_spec/pom.xml
> > Sending        geronimo-interceptor_1.1_spec/pom.xml
> > Sending        geronimo-interceptor_1.2_spec/pom.xml
> > Sending        geronimo-j2ee-connector_1.6_spec/pom.xml
> > Sending        geronimo-jacc_1.1_spec/pom.xml
> > Sending        geronimo-jacc_1.4_spec/pom.xml
> > Sending        geronimo-jaspic_1.0_spec/pom.xml
> > Sending        geronimo-javamail_1.4_spec/pom.xml
> > Sending        geronimo-javamail_1.5_spec/pom.xml
> > Sending        geronimo-jaxb_2.0_spec/pom.xml
> > Sending        geronimo-jaxb_2.1_spec/pom.xml
> > Sending        geronimo-jaxb_2.2_spec/pom.xml
> > Sending        geronimo-jaxr_1.0_spec/pom.xml
> > Sending        geronimo-jaxrpc_1.1_spec/pom.xml
> > Sending        geronimo-jaxrs_1.1_spec/pom.xml
> > Sending        geronimo-jaxrs_2.0_spec/pom.xml
> > Sending        geronimo-jaxrs_2.1_spec/pom.xml
> > Sending        geronimo-jaxws_2.1.1_spec/pom.xml
> > Sending        geronimo-jaxws_2.1_spec/pom.xml
> > Sending        geronimo-jaxws_2.2_spec/pom.xml
> > Sending        geronimo-jbatch_1.0_spec/pom.xml
> > Sending        geronimo-jcache_1.0_spec/pom.xml
> > Sending        geronimo-jcdi_1.0_spec/pom.xml
> > Sending        geronimo-jcdi_1.1_spec/pom.xml
> > Sending        geronimo-jcdi_2.0_spec/pom.xml
> > Sending        geronimo-jms_1.1_spec/pom.xml
> > Sending        geronimo-jms_2.0_spec/pom.xml
> > Sending        geronimo-jpa_1.0_spec/pom.xml
> > Sending        geronimo-jpa_2.0_spec/pom.xml
> > Sending        geronimo-jpa_2.1_spec/pom.xml
> > Sending        geronimo-json_1.0_spec/pom.xml
> > Sending        geronimo-json_1.1_spec/pom.xml
> > Sending        geronimo-jsonb_1.0_spec/pom.xml
> > Sending        geronimo-jsp_2.1_spec/pom.xml
> > Sending        geronimo-jsp_2.2_spec/pom.xml
> > Sending        geronimo-jta_1.1_spec/pom.xml
> > Sending        geronimo-jta_1.2_spec/pom.xml
> > Sending        geronimo-osgi-support/geronimo-osgi-itesta/pom.xml
> > Sending        geronimo-osgi-support/geronimo-osgi-itestb/pom.xml
> > Sending        geronimo-osgi-support/geronimo-osgi-locator/pom.xml
> > Sending        geronimo-osgi-support/geronimo-osgi-registry/pom.xml
> > Sending        geronimo-osgi-support/pom.xml
> > Sending        geronimo-saaj_1.3_spec/pom.xml
> > Sending        geronimo-servlet_2.5_spec/pom.xml
> > Sending        geronimo-servlet_3.0_spec/pom.xml
> > Sending        geronimo-servlet_3.1_spec/pom.xml
> > Sending        geronimo-stax-api_1.0_spec/pom.xml
> > Sending        geronimo-stax-api_1.2_spec/pom.xml
> > Sending        geronimo-validation_1.0_spec/pom.xml
> > Sending        geronimo-validation_1.1_spec/pom.xml
> > Sending        geronimo-validation_2.0_spec/pom.xml
> > Sending        geronimo-websockets_1.0_spec/pom.xml
> > Sending        geronimo-ws-metadata_2.0_spec/pom.xml
> >
> >
> > I've removed ancient specs which are not maintained anymore like the Client Profile.
> >
> > Do we also want to pimp the flava projects? Should I release those as well?
> > The natural order would be to release all the osgi base stuff in one go, then take on a few other specs in bigger bundles until the whole list is worked off.
> >
> > LieGrue,
> > strub
> >
> > > Am 04.06.2018 um 16:36 schrieb Mark Struberg <[hidden email]>:
> > >
> > > I'm with Romain on this one. There is a ticket open for various MP specs.
> > > We should evaluate this and then push for it to be fixed.
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > >> Am 04.06.2018 um 15:09 schrieb Romain Manni-Bucau <[hidden email]>:
> > >>
> > >>
> > >>
> > >> Le lun. 4 juin 2018 à 13:45, John D. Ament <[hidden email]> a écrit :
> > >> 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?
> > >>
> > >> Nop, liberty does it all wrong. They force setGlobalProvider in the API and this is not needed as any geronimo spec jar or aries shows. This leads to an unsafe user accessible API which is not thread safe and a server destructor :(.
> > >> We need https://github.com/apache/geronimo-specs/pull/9 and at least SPI-Provider header, spifly can be nice too - is used today.
> > >>
> > >>
> > >> And the issue with Java 9 is that you can end up with multiple copies of the packages.
> > >>
> > >> This is not really an issue, no more than today actually since it is the same ones with the same content.
> > >>
> > >>
> > >> On Mon, Jun 4, 2018, 7:42 AM Romain Manni-Bucau <[hidden email]> wrote:
> > >>
> > >>
> > >> Le lun. 4 juin 2018 à 13:36, John D. Ament <[hidden email]> 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 <[hidden email]> 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 |  Blog | Old Blog | Github | LinkedIn | Book
> > >>
> > >>
> > >> Le lun. 4 juin 2018 à 09:52, Mark Struberg <[hidden email]> 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 <[hidden email]>:
> > >>>
> > >>> 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
> > >>
> > >
> >
>

Reply | Threaded
Open this post in threaded view
|

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

jlmonteiro
First, sorry because I created another thread.
Well at least it means it was something to discuss :)

I would be also in favor of contributing to MP and adding the missing integration points like OSGi as opposed to copy source code.

Like Mark, I should be able to help in most of them and even probably release.
I agree it was a pain, but let's put this in the context: with all the Jakarta, Microprofile, there have been a lot of changes.
People were not used to the rules @Eclipse. And there were some technical aspects as well.

Did not help probably.




Le mar. 5 juin 2018 à 09:05, Romain Manni-Bucau <[hidden email]> a écrit :
So not needed if we use apache parent pby - this was my point


Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le mar. 5 juin 2018 à 08:41, Mark Struberg <[hidden email]> a écrit :
It contains a few standard plugin settings, but that's really it.

LieGrue,
strub


> Am 05.06.2018 um 06:52 schrieb Romain Manni-Bucau <[hidden email]>:
>
> I know that part but never understood why not using apache parent
>
> Le lun. 4 juin 2018 22:06, Mark Struberg <[hidden email]> a écrit :
> yes, they are the parents for the various g projects.
>
> flava5 is for java5 projects, flava6 for java6,....
>
> LieGrue,
> strub
>
>
> > Am 04.06.2018 um 18:15 schrieb Romain Manni-Bucau <[hidden email]>:
> >
> > Don't recall but do we need flava anymore?
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> >
> >
> > Le lun. 4 juin 2018 à 18:09, Mark Struberg <[hidden email]> a écrit :
> > Just to get this down to paper somehow.
> > The following is a list of specs I'd going to release:
> >
> > Sending        geronimo-activation_1.1_spec/pom.xml
> > Sending        geronimo-annotation_1.2_spec/pom.xml
> > Sending        geronimo-annotation_1.3_spec/pom.xml
> > Sending        geronimo-atinject_1.0_spec/pom.xml
> > Sending        geronimo-availability_1.0_spec/pom.xml
> > Sending        geronimo-concurrent_1.0_spec/pom.xml
> > Sending        geronimo-ejb_3.1_spec/pom.xml
> > Sending        geronimo-ejb_3.2_spec/pom.xml
> > Sending        geronimo-el_2.2_spec/pom.xml
> > Sending        geronimo-interceptor_1.1_spec/pom.xml
> > Sending        geronimo-interceptor_1.2_spec/pom.xml
> > Sending        geronimo-j2ee-connector_1.6_spec/pom.xml
> > Sending        geronimo-jacc_1.1_spec/pom.xml
> > Sending        geronimo-jacc_1.4_spec/pom.xml
> > Sending        geronimo-jaspic_1.0_spec/pom.xml
> > Sending        geronimo-javamail_1.4_spec/pom.xml
> > Sending        geronimo-javamail_1.5_spec/pom.xml
> > Sending        geronimo-jaxb_2.0_spec/pom.xml
> > Sending        geronimo-jaxb_2.1_spec/pom.xml
> > Sending        geronimo-jaxb_2.2_spec/pom.xml
> > Sending        geronimo-jaxr_1.0_spec/pom.xml
> > Sending        geronimo-jaxrpc_1.1_spec/pom.xml
> > Sending        geronimo-jaxrs_1.1_spec/pom.xml
> > Sending        geronimo-jaxrs_2.0_spec/pom.xml
> > Sending        geronimo-jaxrs_2.1_spec/pom.xml
> > Sending        geronimo-jaxws_2.1.1_spec/pom.xml
> > Sending        geronimo-jaxws_2.1_spec/pom.xml
> > Sending        geronimo-jaxws_2.2_spec/pom.xml
> > Sending        geronimo-jbatch_1.0_spec/pom.xml
> > Sending        geronimo-jcache_1.0_spec/pom.xml
> > Sending        geronimo-jcdi_1.0_spec/pom.xml
> > Sending        geronimo-jcdi_1.1_spec/pom.xml
> > Sending        geronimo-jcdi_2.0_spec/pom.xml
> > Sending        geronimo-jms_1.1_spec/pom.xml
> > Sending        geronimo-jms_2.0_spec/pom.xml
> > Sending        geronimo-jpa_1.0_spec/pom.xml
> > Sending        geronimo-jpa_2.0_spec/pom.xml
> > Sending        geronimo-jpa_2.1_spec/pom.xml
> > Sending        geronimo-json_1.0_spec/pom.xml
> > Sending        geronimo-json_1.1_spec/pom.xml
> > Sending        geronimo-jsonb_1.0_spec/pom.xml
> > Sending        geronimo-jsp_2.1_spec/pom.xml
> > Sending        geronimo-jsp_2.2_spec/pom.xml
> > Sending        geronimo-jta_1.1_spec/pom.xml
> > Sending        geronimo-jta_1.2_spec/pom.xml
> > Sending        geronimo-osgi-support/geronimo-osgi-itesta/pom.xml
> > Sending        geronimo-osgi-support/geronimo-osgi-itestb/pom.xml
> > Sending        geronimo-osgi-support/geronimo-osgi-locator/pom.xml
> > Sending        geronimo-osgi-support/geronimo-osgi-registry/pom.xml
> > Sending        geronimo-osgi-support/pom.xml
> > Sending        geronimo-saaj_1.3_spec/pom.xml
> > Sending        geronimo-servlet_2.5_spec/pom.xml
> > Sending        geronimo-servlet_3.0_spec/pom.xml
> > Sending        geronimo-servlet_3.1_spec/pom.xml
> > Sending        geronimo-stax-api_1.0_spec/pom.xml
> > Sending        geronimo-stax-api_1.2_spec/pom.xml
> > Sending        geronimo-validation_1.0_spec/pom.xml
> > Sending        geronimo-validation_1.1_spec/pom.xml
> > Sending        geronimo-validation_2.0_spec/pom.xml
> > Sending        geronimo-websockets_1.0_spec/pom.xml
> > Sending        geronimo-ws-metadata_2.0_spec/pom.xml
> >
> >
> > I've removed ancient specs which are not maintained anymore like the Client Profile.
> >
> > Do we also want to pimp the flava projects? Should I release those as well?
> > The natural order would be to release all the osgi base stuff in one go, then take on a few other specs in bigger bundles until the whole list is worked off.
> >
> > LieGrue,
> > strub
> >
> > > Am 04.06.2018 um 16:36 schrieb Mark Struberg <[hidden email]>:
> > >
> > > I'm with Romain on this one. There is a ticket open for various MP specs.
> > > We should evaluate this and then push for it to be fixed.
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > >> Am 04.06.2018 um 15:09 schrieb Romain Manni-Bucau <[hidden email]>:
> > >>
> > >>
> > >>
> > >> Le lun. 4 juin 2018 à 13:45, John D. Ament <[hidden email]> a écrit :
> > >> 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?
> > >>
> > >> Nop, liberty does it all wrong. They force setGlobalProvider in the API and this is not needed as any geronimo spec jar or aries shows. This leads to an unsafe user accessible API which is not thread safe and a server destructor :(.
> > >> We need https://github.com/apache/geronimo-specs/pull/9 and at least SPI-Provider header, spifly can be nice too - is used today.
> > >>
> > >>
> > >> And the issue with Java 9 is that you can end up with multiple copies of the packages.
> > >>
> > >> This is not really an issue, no more than today actually since it is the same ones with the same content.
> > >>
> > >>
> > >> On Mon, Jun 4, 2018, 7:42 AM Romain Manni-Bucau <[hidden email]> wrote:
> > >>
> > >>
> > >> Le lun. 4 juin 2018 à 13:36, John D. Ament <[hidden email]> 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 <[hidden email]> 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 |  Blog | Old Blog | Github | LinkedIn | Book
> > >>
> > >>
> > >> Le lun. 4 juin 2018 à 09:52, Mark Struberg <[hidden email]> 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 <[hidden email]>:
> > >>>
> > >>> 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
> > >>
> > >
> >
>

Reply | Threaded
Open this post in threaded view
|

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

Romain Manni-Bucau
I see, so what about this one: for now we stay like we are @G and once eclipse has released spifly/provider header/contracts meta we drop them since they prooved we dont need it anymore.

Does it sound like a plan?

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le mar. 5 juin 2018 à 09:14, Jean-Louis MONTEIRO <[hidden email]> a écrit :
First, sorry because I created another thread.
Well at least it means it was something to discuss :)

I would be also in favor of contributing to MP and adding the missing integration points like OSGi as opposed to copy source code.

Like Mark, I should be able to help in most of them and even probably release.
I agree it was a pain, but let's put this in the context: with all the Jakarta, Microprofile, there have been a lot of changes.
People were not used to the rules @Eclipse. And there were some technical aspects as well.

Did not help probably.




Le mar. 5 juin 2018 à 09:05, Romain Manni-Bucau <[hidden email]> a écrit :
So not needed if we use apache parent pby - this was my point


Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le mar. 5 juin 2018 à 08:41, Mark Struberg <[hidden email]> a écrit :
It contains a few standard plugin settings, but that's really it.

LieGrue,
strub


> Am 05.06.2018 um 06:52 schrieb Romain Manni-Bucau <[hidden email]>:
>
> I know that part but never understood why not using apache parent
>
> Le lun. 4 juin 2018 22:06, Mark Struberg <[hidden email]> a écrit :
> yes, they are the parents for the various g projects.
>
> flava5 is for java5 projects, flava6 for java6,....
>
> LieGrue,
> strub
>
>
> > Am 04.06.2018 um 18:15 schrieb Romain Manni-Bucau <[hidden email]>:
> >
> > Don't recall but do we need flava anymore?
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> >
> >
> > Le lun. 4 juin 2018 à 18:09, Mark Struberg <[hidden email]> a écrit :
> > Just to get this down to paper somehow.
> > The following is a list of specs I'd going to release:
> >
> > Sending        geronimo-activation_1.1_spec/pom.xml
> > Sending        geronimo-annotation_1.2_spec/pom.xml
> > Sending        geronimo-annotation_1.3_spec/pom.xml
> > Sending        geronimo-atinject_1.0_spec/pom.xml
> > Sending        geronimo-availability_1.0_spec/pom.xml
> > Sending        geronimo-concurrent_1.0_spec/pom.xml
> > Sending        geronimo-ejb_3.1_spec/pom.xml
> > Sending        geronimo-ejb_3.2_spec/pom.xml
> > Sending        geronimo-el_2.2_spec/pom.xml
> > Sending        geronimo-interceptor_1.1_spec/pom.xml
> > Sending        geronimo-interceptor_1.2_spec/pom.xml
> > Sending        geronimo-j2ee-connector_1.6_spec/pom.xml
> > Sending        geronimo-jacc_1.1_spec/pom.xml
> > Sending        geronimo-jacc_1.4_spec/pom.xml
> > Sending        geronimo-jaspic_1.0_spec/pom.xml
> > Sending        geronimo-javamail_1.4_spec/pom.xml
> > Sending        geronimo-javamail_1.5_spec/pom.xml
> > Sending        geronimo-jaxb_2.0_spec/pom.xml
> > Sending        geronimo-jaxb_2.1_spec/pom.xml
> > Sending        geronimo-jaxb_2.2_spec/pom.xml
> > Sending        geronimo-jaxr_1.0_spec/pom.xml
> > Sending        geronimo-jaxrpc_1.1_spec/pom.xml
> > Sending        geronimo-jaxrs_1.1_spec/pom.xml
> > Sending        geronimo-jaxrs_2.0_spec/pom.xml
> > Sending        geronimo-jaxrs_2.1_spec/pom.xml
> > Sending        geronimo-jaxws_2.1.1_spec/pom.xml
> > Sending        geronimo-jaxws_2.1_spec/pom.xml
> > Sending        geronimo-jaxws_2.2_spec/pom.xml
> > Sending        geronimo-jbatch_1.0_spec/pom.xml
> > Sending        geronimo-jcache_1.0_spec/pom.xml
> > Sending        geronimo-jcdi_1.0_spec/pom.xml
> > Sending        geronimo-jcdi_1.1_spec/pom.xml
> > Sending        geronimo-jcdi_2.0_spec/pom.xml
> > Sending        geronimo-jms_1.1_spec/pom.xml
> > Sending        geronimo-jms_2.0_spec/pom.xml
> > Sending        geronimo-jpa_1.0_spec/pom.xml
> > Sending        geronimo-jpa_2.0_spec/pom.xml
> > Sending        geronimo-jpa_2.1_spec/pom.xml
> > Sending        geronimo-json_1.0_spec/pom.xml
> > Sending        geronimo-json_1.1_spec/pom.xml
> > Sending        geronimo-jsonb_1.0_spec/pom.xml
> > Sending        geronimo-jsp_2.1_spec/pom.xml
> > Sending        geronimo-jsp_2.2_spec/pom.xml
> > Sending        geronimo-jta_1.1_spec/pom.xml
> > Sending        geronimo-jta_1.2_spec/pom.xml
> > Sending        geronimo-osgi-support/geronimo-osgi-itesta/pom.xml
> > Sending        geronimo-osgi-support/geronimo-osgi-itestb/pom.xml
> > Sending        geronimo-osgi-support/geronimo-osgi-locator/pom.xml
> > Sending        geronimo-osgi-support/geronimo-osgi-registry/pom.xml
> > Sending        geronimo-osgi-support/pom.xml
> > Sending        geronimo-saaj_1.3_spec/pom.xml
> > Sending        geronimo-servlet_2.5_spec/pom.xml
> > Sending        geronimo-servlet_3.0_spec/pom.xml
> > Sending        geronimo-servlet_3.1_spec/pom.xml
> > Sending        geronimo-stax-api_1.0_spec/pom.xml
> > Sending        geronimo-stax-api_1.2_spec/pom.xml
> > Sending        geronimo-validation_1.0_spec/pom.xml
> > Sending        geronimo-validation_1.1_spec/pom.xml
> > Sending        geronimo-validation_2.0_spec/pom.xml
> > Sending        geronimo-websockets_1.0_spec/pom.xml
> > Sending        geronimo-ws-metadata_2.0_spec/pom.xml
> >
> >
> > I've removed ancient specs which are not maintained anymore like the Client Profile.
> >
> > Do we also want to pimp the flava projects? Should I release those as well?
> > The natural order would be to release all the osgi base stuff in one go, then take on a few other specs in bigger bundles until the whole list is worked off.
> >
> > LieGrue,
> > strub
> >
> > > Am 04.06.2018 um 16:36 schrieb Mark Struberg <[hidden email]>:
> > >
> > > I'm with Romain on this one. There is a ticket open for various MP specs.
> > > We should evaluate this and then push for it to be fixed.
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > >> Am 04.06.2018 um 15:09 schrieb Romain Manni-Bucau <[hidden email]>:
> > >>
> > >>
> > >>
> > >> Le lun. 4 juin 2018 à 13:45, John D. Ament <[hidden email]> a écrit :
> > >> 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?
> > >>
> > >> Nop, liberty does it all wrong. They force setGlobalProvider in the API and this is not needed as any geronimo spec jar or aries shows. This leads to an unsafe user accessible API which is not thread safe and a server destructor :(.
> > >> We need https://github.com/apache/geronimo-specs/pull/9 and at least SPI-Provider header, spifly can be nice too - is used today.
> > >>
> > >>
> > >> And the issue with Java 9 is that you can end up with multiple copies of the packages.
> > >>
> > >> This is not really an issue, no more than today actually since it is the same ones with the same content.
> > >>
> > >>
> > >> On Mon, Jun 4, 2018, 7:42 AM Romain Manni-Bucau <[hidden email]> wrote:
> > >>
> > >>
> > >> Le lun. 4 juin 2018 à 13:36, John D. Ament <[hidden email]> 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 <[hidden email]> 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 |  Blog | Old Blog | Github | LinkedIn | Book
> > >>
> > >>
> > >> Le lun. 4 juin 2018 à 09:52, Mark Struberg <[hidden email]> 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 <[hidden email]>:
> > >>>
> > >>> 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
> > >>
> > >
> >
>

Reply | Threaded
Open this post in threaded view
|

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

jlmonteiro
Sounds a good plan.

Can you send a PR on the eclipse projects?
I can review them there and most likely get them merged or help pushing



Le mar. 5 juin 2018 à 09:36, Romain Manni-Bucau <[hidden email]> a écrit :
I see, so what about this one: for now we stay like we are @G and once eclipse has released spifly/provider header/contracts meta we drop them since they prooved we dont need it anymore.

Does it sound like a plan?


Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le mar. 5 juin 2018 à 09:14, Jean-Louis MONTEIRO <[hidden email]> a écrit :
First, sorry because I created another thread.
Well at least it means it was something to discuss :)

I would be also in favor of contributing to MP and adding the missing integration points like OSGi as opposed to copy source code.

Like Mark, I should be able to help in most of them and even probably release.
I agree it was a pain, but let's put this in the context: with all the Jakarta, Microprofile, there have been a lot of changes.
People were not used to the rules @Eclipse. And there were some technical aspects as well.

Did not help probably.




Le mar. 5 juin 2018 à 09:05, Romain Manni-Bucau <[hidden email]> a écrit :
So not needed if we use apache parent pby - this was my point


Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le mar. 5 juin 2018 à 08:41, Mark Struberg <[hidden email]> a écrit :
It contains a few standard plugin settings, but that's really it.

LieGrue,
strub


> Am 05.06.2018 um 06:52 schrieb Romain Manni-Bucau <[hidden email]>:
>
> I know that part but never understood why not using apache parent
>
> Le lun. 4 juin 2018 22:06, Mark Struberg <[hidden email]> a écrit :
> yes, they are the parents for the various g projects.
>
> flava5 is for java5 projects, flava6 for java6,....
>
> LieGrue,
> strub
>
>
> > Am 04.06.2018 um 18:15 schrieb Romain Manni-Bucau <[hidden email]>:
> >
> > Don't recall but do we need flava anymore?
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> >
> >
> > Le lun. 4 juin 2018 à 18:09, Mark Struberg <[hidden email]> a écrit :
> > Just to get this down to paper somehow.
> > The following is a list of specs I'd going to release:
> >
> > Sending        geronimo-activation_1.1_spec/pom.xml
> > Sending        geronimo-annotation_1.2_spec/pom.xml
> > Sending        geronimo-annotation_1.3_spec/pom.xml
> > Sending        geronimo-atinject_1.0_spec/pom.xml
> > Sending        geronimo-availability_1.0_spec/pom.xml
> > Sending        geronimo-concurrent_1.0_spec/pom.xml
> > Sending        geronimo-ejb_3.1_spec/pom.xml
> > Sending        geronimo-ejb_3.2_spec/pom.xml
> > Sending        geronimo-el_2.2_spec/pom.xml
> > Sending        geronimo-interceptor_1.1_spec/pom.xml
> > Sending        geronimo-interceptor_1.2_spec/pom.xml
> > Sending        geronimo-j2ee-connector_1.6_spec/pom.xml
> > Sending        geronimo-jacc_1.1_spec/pom.xml
> > Sending        geronimo-jacc_1.4_spec/pom.xml
> > Sending        geronimo-jaspic_1.0_spec/pom.xml
> > Sending        geronimo-javamail_1.4_spec/pom.xml
> > Sending        geronimo-javamail_1.5_spec/pom.xml
> > Sending        geronimo-jaxb_2.0_spec/pom.xml
> > Sending        geronimo-jaxb_2.1_spec/pom.xml
> > Sending        geronimo-jaxb_2.2_spec/pom.xml
> > Sending        geronimo-jaxr_1.0_spec/pom.xml
> > Sending        geronimo-jaxrpc_1.1_spec/pom.xml
> > Sending        geronimo-jaxrs_1.1_spec/pom.xml
> > Sending        geronimo-jaxrs_2.0_spec/pom.xml
> > Sending        geronimo-jaxrs_2.1_spec/pom.xml
> > Sending        geronimo-jaxws_2.1.1_spec/pom.xml
> > Sending        geronimo-jaxws_2.1_spec/pom.xml
> > Sending        geronimo-jaxws_2.2_spec/pom.xml
> > Sending        geronimo-jbatch_1.0_spec/pom.xml
> > Sending        geronimo-jcache_1.0_spec/pom.xml
> > Sending        geronimo-jcdi_1.0_spec/pom.xml
> > Sending        geronimo-jcdi_1.1_spec/pom.xml
> > Sending        geronimo-jcdi_2.0_spec/pom.xml
> > Sending        geronimo-jms_1.1_spec/pom.xml
> > Sending        geronimo-jms_2.0_spec/pom.xml
> > Sending        geronimo-jpa_1.0_spec/pom.xml
> > Sending        geronimo-jpa_2.0_spec/pom.xml
> > Sending        geronimo-jpa_2.1_spec/pom.xml
> > Sending        geronimo-json_1.0_spec/pom.xml
> > Sending        geronimo-json_1.1_spec/pom.xml
> > Sending        geronimo-jsonb_1.0_spec/pom.xml
> > Sending        geronimo-jsp_2.1_spec/pom.xml
> > Sending        geronimo-jsp_2.2_spec/pom.xml
> > Sending        geronimo-jta_1.1_spec/pom.xml
> > Sending        geronimo-jta_1.2_spec/pom.xml
> > Sending        geronimo-osgi-support/geronimo-osgi-itesta/pom.xml
> > Sending        geronimo-osgi-support/geronimo-osgi-itestb/pom.xml
> > Sending        geronimo-osgi-support/geronimo-osgi-locator/pom.xml
> > Sending        geronimo-osgi-support/geronimo-osgi-registry/pom.xml
> > Sending        geronimo-osgi-support/pom.xml
> > Sending        geronimo-saaj_1.3_spec/pom.xml
> > Sending        geronimo-servlet_2.5_spec/pom.xml
> > Sending        geronimo-servlet_3.0_spec/pom.xml
> > Sending        geronimo-servlet_3.1_spec/pom.xml
> > Sending        geronimo-stax-api_1.0_spec/pom.xml
> > Sending        geronimo-stax-api_1.2_spec/pom.xml
> > Sending        geronimo-validation_1.0_spec/pom.xml
> > Sending        geronimo-validation_1.1_spec/pom.xml
> > Sending        geronimo-validation_2.0_spec/pom.xml
> > Sending        geronimo-websockets_1.0_spec/pom.xml
> > Sending        geronimo-ws-metadata_2.0_spec/pom.xml
> >
> >
> > I've removed ancient specs which are not maintained anymore like the Client Profile.
> >
> > Do we also want to pimp the flava projects? Should I release those as well?
> > The natural order would be to release all the osgi base stuff in one go, then take on a few other specs in bigger bundles until the whole list is worked off.
> >
> > LieGrue,
> > strub
> >
> > > Am 04.06.2018 um 16:36 schrieb Mark Struberg <[hidden email]>:
> > >
> > > I'm with Romain on this one. There is a ticket open for various MP specs.
> > > We should evaluate this and then push for it to be fixed.
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > >> Am 04.06.2018 um 15:09 schrieb Romain Manni-Bucau <[hidden email]>:
> > >>
> > >>
> > >>
> > >> Le lun. 4 juin 2018 à 13:45, John D. Ament <[hidden email]> a écrit :
> > >> 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?
> > >>
> > >> Nop, liberty does it all wrong. They force setGlobalProvider in the API and this is not needed as any geronimo spec jar or aries shows. This leads to an unsafe user accessible API which is not thread safe and a server destructor :(.
> > >> We need https://github.com/apache/geronimo-specs/pull/9 and at least SPI-Provider header, spifly can be nice too - is used today.
> > >>
> > >>
> > >> And the issue with Java 9 is that you can end up with multiple copies of the packages.
> > >>
> > >> This is not really an issue, no more than today actually since it is the same ones with the same content.
> > >>
> > >>
> > >> On Mon, Jun 4, 2018, 7:42 AM Romain Manni-Bucau <[hidden email]> wrote:
> > >>
> > >>
> > >> Le lun. 4 juin 2018 à 13:36, John D. Ament <[hidden email]> 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 <[hidden email]> 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 |  Blog | Old Blog | Github | LinkedIn | Book
> > >>
> > >>
> > >> Le lun. 4 juin 2018 à 09:52, Mark Struberg <[hidden email]> 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 <[hidden email]>:
> > >>>
> > >>> 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
> > >>
> > >
> >
>

Reply | Threaded
Open this post in threaded view
|

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

Romain Manni-Bucau
I don't have them handy but maybe we should get in touch with aries guys. Seems current OSGi@MP is driven by liberty profile and they don't seem to be aware of recent OSGi update leading to API pollution which is pretty bad for end users.
Will try to ping a few OSGi@asf guys I know to get help on that.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le mar. 5 juin 2018 à 09:55, Jean-Louis MONTEIRO <[hidden email]> a écrit :
Sounds a good plan.

Can you send a PR on the eclipse projects?
I can review them there and most likely get them merged or help pushing



Le mar. 5 juin 2018 à 09:36, Romain Manni-Bucau <[hidden email]> a écrit :
I see, so what about this one: for now we stay like we are @G and once eclipse has released spifly/provider header/contracts meta we drop them since they prooved we dont need it anymore.

Does it sound like a plan?


Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le mar. 5 juin 2018 à 09:14, Jean-Louis MONTEIRO <[hidden email]> a écrit :
First, sorry because I created another thread.
Well at least it means it was something to discuss :)

I would be also in favor of contributing to MP and adding the missing integration points like OSGi as opposed to copy source code.

Like Mark, I should be able to help in most of them and even probably release.
I agree it was a pain, but let's put this in the context: with all the Jakarta, Microprofile, there have been a lot of changes.
People were not used to the rules @Eclipse. And there were some technical aspects as well.

Did not help probably.




Le mar. 5 juin 2018 à 09:05, Romain Manni-Bucau <[hidden email]> a écrit :
So not needed if we use apache parent pby - this was my point


Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le mar. 5 juin 2018 à 08:41, Mark Struberg <[hidden email]> a écrit :
It contains a few standard plugin settings, but that's really it.

LieGrue,
strub


> Am 05.06.2018 um 06:52 schrieb Romain Manni-Bucau <[hidden email]>:
>
> I know that part but never understood why not using apache parent
>
> Le lun. 4 juin 2018 22:06, Mark Struberg <[hidden email]> a écrit :
> yes, they are the parents for the various g projects.
>
> flava5 is for java5 projects, flava6 for java6,....
>
> LieGrue,
> strub
>
>
> > Am 04.06.2018 um 18:15 schrieb Romain Manni-Bucau <[hidden email]>:
> >
> > Don't recall but do we need flava anymore?
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> >
> >
> > Le lun. 4 juin 2018 à 18:09, Mark Struberg <[hidden email]> a écrit :
> > Just to get this down to paper somehow.
> > The following is a list of specs I'd going to release:
> >
> > Sending        geronimo-activation_1.1_spec/pom.xml
> > Sending        geronimo-annotation_1.2_spec/pom.xml
> > Sending        geronimo-annotation_1.3_spec/pom.xml
> > Sending        geronimo-atinject_1.0_spec/pom.xml
> > Sending        geronimo-availability_1.0_spec/pom.xml
> > Sending        geronimo-concurrent_1.0_spec/pom.xml
> > Sending        geronimo-ejb_3.1_spec/pom.xml
> > Sending        geronimo-ejb_3.2_spec/pom.xml
> > Sending        geronimo-el_2.2_spec/pom.xml
> > Sending        geronimo-interceptor_1.1_spec/pom.xml
> > Sending        geronimo-interceptor_1.2_spec/pom.xml
> > Sending        geronimo-j2ee-connector_1.6_spec/pom.xml
> > Sending        geronimo-jacc_1.1_spec/pom.xml
> > Sending        geronimo-jacc_1.4_spec/pom.xml
> > Sending        geronimo-jaspic_1.0_spec/pom.xml
> > Sending        geronimo-javamail_1.4_spec/pom.xml
> > Sending        geronimo-javamail_1.5_spec/pom.xml
> > Sending        geronimo-jaxb_2.0_spec/pom.xml
> > Sending        geronimo-jaxb_2.1_spec/pom.xml
> > Sending        geronimo-jaxb_2.2_spec/pom.xml
> > Sending        geronimo-jaxr_1.0_spec/pom.xml
> > Sending        geronimo-jaxrpc_1.1_spec/pom.xml
> > Sending        geronimo-jaxrs_1.1_spec/pom.xml
> > Sending        geronimo-jaxrs_2.0_spec/pom.xml
> > Sending        geronimo-jaxrs_2.1_spec/pom.xml
> > Sending        geronimo-jaxws_2.1.1_spec/pom.xml
> > Sending        geronimo-jaxws_2.1_spec/pom.xml
> > Sending        geronimo-jaxws_2.2_spec/pom.xml
> > Sending        geronimo-jbatch_1.0_spec/pom.xml
> > Sending        geronimo-jcache_1.0_spec/pom.xml
> > Sending        geronimo-jcdi_1.0_spec/pom.xml
> > Sending        geronimo-jcdi_1.1_spec/pom.xml
> > Sending        geronimo-jcdi_2.0_spec/pom.xml
> > Sending        geronimo-jms_1.1_spec/pom.xml
> > Sending        geronimo-jms_2.0_spec/pom.xml
> > Sending        geronimo-jpa_1.0_spec/pom.xml
> > Sending        geronimo-jpa_2.0_spec/pom.xml
> > Sending        geronimo-jpa_2.1_spec/pom.xml
> > Sending        geronimo-json_1.0_spec/pom.xml
> > Sending        geronimo-json_1.1_spec/pom.xml
> > Sending        geronimo-jsonb_1.0_spec/pom.xml
> > Sending        geronimo-jsp_2.1_spec/pom.xml
> > Sending        geronimo-jsp_2.2_spec/pom.xml
> > Sending        geronimo-jta_1.1_spec/pom.xml
> > Sending        geronimo-jta_1.2_spec/pom.xml
> > Sending        geronimo-osgi-support/geronimo-osgi-itesta/pom.xml
> > Sending        geronimo-osgi-support/geronimo-osgi-itestb/pom.xml
> > Sending        geronimo-osgi-support/geronimo-osgi-locator/pom.xml
> > Sending        geronimo-osgi-support/geronimo-osgi-registry/pom.xml
> > Sending        geronimo-osgi-support/pom.xml
> > Sending        geronimo-saaj_1.3_spec/pom.xml
> > Sending        geronimo-servlet_2.5_spec/pom.xml
> > Sending        geronimo-servlet_3.0_spec/pom.xml
> > Sending        geronimo-servlet_3.1_spec/pom.xml
> > Sending        geronimo-stax-api_1.0_spec/pom.xml
> > Sending        geronimo-stax-api_1.2_spec/pom.xml
> > Sending        geronimo-validation_1.0_spec/pom.xml
> > Sending        geronimo-validation_1.1_spec/pom.xml
> > Sending        geronimo-validation_2.0_spec/pom.xml
> > Sending        geronimo-websockets_1.0_spec/pom.xml
> > Sending        geronimo-ws-metadata_2.0_spec/pom.xml
> >
> >
> > I've removed ancient specs which are not maintained anymore like the Client Profile.
> >
> > Do we also want to pimp the flava projects? Should I release those as well?
> > The natural order would be to release all the osgi base stuff in one go, then take on a few other specs in bigger bundles until the whole list is worked off.
> >
> > LieGrue,
> > strub
> >
> > > Am 04.06.2018 um 16:36 schrieb Mark Struberg <[hidden email]>:
> > >
> > > I'm with Romain on this one. There is a ticket open for various MP specs.
> > > We should evaluate this and then push for it to be fixed.
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > >> Am 04.06.2018 um 15:09 schrieb Romain Manni-Bucau <[hidden email]>:
> > >>
> > >>
> > >>
> > >> Le lun. 4 juin 2018 à 13:45, John D. Ament <[hidden email]> a écrit :
> > >> 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?
> > >>
> > >> Nop, liberty does it all wrong. They force setGlobalProvider in the API and this is not needed as any geronimo spec jar or aries shows. This leads to an unsafe user accessible API which is not thread safe and a server destructor :(.
> > >> We need https://github.com/apache/geronimo-specs/pull/9 and at least SPI-Provider header, spifly can be nice too - is used today.
> > >>
> > >>
> > >> And the issue with Java 9 is that you can end up with multiple copies of the packages.
> > >>
> > >> This is not really an issue, no more than today actually since it is the same ones with the same content.
> > >>
> > >>
> > >> On Mon, Jun 4, 2018, 7:42 AM Romain Manni-Bucau <[hidden email]> wrote:
> > >>
> > >>
> > >> Le lun. 4 juin 2018 à 13:36, John D. Ament <[hidden email]> 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 <[hidden email]> 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 |  Blog | Old Blog | Github | LinkedIn | Book
> > >>
> > >>
> > >> Le lun. 4 juin 2018 à 09:52, Mark Struberg <[hidden email]> 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 <[hidden email]>:
> > >>>
> > >>> 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
> > >>
> > >
> >
>

Reply | Threaded
Open this post in threaded view
|

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

jlmonteiro
Sounds great. Thanks

Le mar. 5 juin 2018 à 09:58, Romain Manni-Bucau <[hidden email]> a écrit :
I don't have them handy but maybe we should get in touch with aries guys. Seems current OSGi@MP is driven by liberty profile and they don't seem to be aware of recent OSGi update leading to API pollution which is pretty bad for end users.
Will try to ping a few OSGi@asf guys I know to get help on that.


Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le mar. 5 juin 2018 à 09:55, Jean-Louis MONTEIRO <[hidden email]> a écrit :
Sounds a good plan.

Can you send a PR on the eclipse projects?
I can review them there and most likely get them merged or help pushing



Le mar. 5 juin 2018 à 09:36, Romain Manni-Bucau <[hidden email]> a écrit :
I see, so what about this one: for now we stay like we are @G and once eclipse has released spifly/provider header/contracts meta we drop them since they prooved we dont need it anymore.

Does it sound like a plan?


Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le mar. 5 juin 2018 à 09:14, Jean-Louis MONTEIRO <[hidden email]> a écrit :
First, sorry because I created another thread.
Well at least it means it was something to discuss :)

I would be also in favor of contributing to MP and adding the missing integration points like OSGi as opposed to copy source code.

Like Mark, I should be able to help in most of them and even probably release.
I agree it was a pain, but let's put this in the context: with all the Jakarta, Microprofile, there have been a lot of changes.
People were not used to the rules @Eclipse. And there were some technical aspects as well.

Did not help probably.




Le mar. 5 juin 2018 à 09:05, Romain Manni-Bucau <[hidden email]> a écrit :
So not needed if we use apache parent pby - this was my point


Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le mar. 5 juin 2018 à 08:41, Mark Struberg <[hidden email]> a écrit :
It contains a few standard plugin settings, but that's really it.

LieGrue,
strub


> Am 05.06.2018 um 06:52 schrieb Romain Manni-Bucau <[hidden email]>:
>
> I know that part but never understood why not using apache parent
>
> Le lun. 4 juin 2018 22:06, Mark Struberg <[hidden email]> a écrit :
> yes, they are the parents for the various g projects.
>
> flava5 is for java5 projects, flava6 for java6,....
>
> LieGrue,
> strub
>
>
> > Am 04.06.2018 um 18:15 schrieb Romain Manni-Bucau <[hidden email]>:
> >
> > Don't recall but do we need flava anymore?
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> >
> >
> > Le lun. 4 juin 2018 à 18:09, Mark Struberg <[hidden email]> a écrit :
> > Just to get this down to paper somehow.
> > The following is a list of specs I'd going to release:
> >
> > Sending        geronimo-activation_1.1_spec/pom.xml
> > Sending        geronimo-annotation_1.2_spec/pom.xml
> > Sending        geronimo-annotation_1.3_spec/pom.xml
> > Sending        geronimo-atinject_1.0_spec/pom.xml
> > Sending        geronimo-availability_1.0_spec/pom.xml
> > Sending        geronimo-concurrent_1.0_spec/pom.xml
> > Sending        geronimo-ejb_3.1_spec/pom.xml
> > Sending        geronimo-ejb_3.2_spec/pom.xml
> > Sending        geronimo-el_2.2_spec/pom.xml
> > Sending        geronimo-interceptor_1.1_spec/pom.xml
> > Sending        geronimo-interceptor_1.2_spec/pom.xml
> > Sending        geronimo-j2ee-connector_1.6_spec/pom.xml
> > Sending        geronimo-jacc_1.1_spec/pom.xml
> > Sending        geronimo-jacc_1.4_spec/pom.xml
> > Sending        geronimo-jaspic_1.0_spec/pom.xml
> > Sending        geronimo-javamail_1.4_spec/pom.xml
> > Sending        geronimo-javamail_1.5_spec/pom.xml
> > Sending        geronimo-jaxb_2.0_spec/pom.xml
> > Sending        geronimo-jaxb_2.1_spec/pom.xml
> > Sending        geronimo-jaxb_2.2_spec/pom.xml
> > Sending        geronimo-jaxr_1.0_spec/pom.xml
> > Sending        geronimo-jaxrpc_1.1_spec/pom.xml
> > Sending        geronimo-jaxrs_1.1_spec/pom.xml
> > Sending        geronimo-jaxrs_2.0_spec/pom.xml
> > Sending        geronimo-jaxrs_2.1_spec/pom.xml
> > Sending        geronimo-jaxws_2.1.1_spec/pom.xml
> > Sending        geronimo-jaxws_2.1_spec/pom.xml
> > Sending        geronimo-jaxws_2.2_spec/pom.xml
> > Sending        geronimo-jbatch_1.0_spec/pom.xml
> > Sending        geronimo-jcache_1.0_spec/pom.xml
> > Sending        geronimo-jcdi_1.0_spec/pom.xml
> > Sending        geronimo-jcdi_1.1_spec/pom.xml
> > Sending        geronimo-jcdi_2.0_spec/pom.xml
> > Sending        geronimo-jms_1.1_spec/pom.xml
> > Sending        geronimo-jms_2.0_spec/pom.xml
> > Sending        geronimo-jpa_1.0_spec/pom.xml
> > Sending        geronimo-jpa_2.0_spec/pom.xml
> > Sending        geronimo-jpa_2.1_spec/pom.xml
> > Sending        geronimo-json_1.0_spec/pom.xml
> > Sending        geronimo-json_1.1_spec/pom.xml
> > Sending        geronimo-jsonb_1.0_spec/pom.xml
> > Sending        geronimo-jsp_2.1_spec/pom.xml
> > Sending        geronimo-jsp_2.2_spec/pom.xml
> > Sending        geronimo-jta_1.1_spec/pom.xml
> > Sending        geronimo-jta_1.2_spec/pom.xml
> > Sending        geronimo-osgi-support/geronimo-osgi-itesta/pom.xml
> > Sending        geronimo-osgi-support/geronimo-osgi-itestb/pom.xml
> > Sending        geronimo-osgi-support/geronimo-osgi-locator/pom.xml
> > Sending        geronimo-osgi-support/geronimo-osgi-registry/pom.xml
> > Sending        geronimo-osgi-support/pom.xml
> > Sending        geronimo-saaj_1.3_spec/pom.xml
> > Sending        geronimo-servlet_2.5_spec/pom.xml
> > Sending        geronimo-servlet_3.0_spec/pom.xml
> > Sending        geronimo-servlet_3.1_spec/pom.xml
> > Sending        geronimo-stax-api_1.0_spec/pom.xml
> > Sending        geronimo-stax-api_1.2_spec/pom.xml
> > Sending        geronimo-validation_1.0_spec/pom.xml
> > Sending        geronimo-validation_1.1_spec/pom.xml
> > Sending        geronimo-validation_2.0_spec/pom.xml
> > Sending        geronimo-websockets_1.0_spec/pom.xml
> > Sending        geronimo-ws-metadata_2.0_spec/pom.xml
> >
> >
> > I've removed ancient specs which are not maintained anymore like the Client Profile.
> >
> > Do we also want to pimp the flava projects? Should I release those as well?
> > The natural order would be to release all the osgi base stuff in one go, then take on a few other specs in bigger bundles until the whole list is worked off.
> >
> > LieGrue,
> > strub
> >
> > > Am 04.06.2018 um 16:36 schrieb Mark Struberg <[hidden email]>:
> > >
> > > I'm with Romain on this one. There is a ticket open for various MP specs.
> > > We should evaluate this and then push for it to be fixed.
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > >> Am 04.06.2018 um 15:09 schrieb Romain Manni-Bucau <[hidden email]>:
> > >>
> > >>
> > >>
> > >> Le lun. 4 juin 2018 à 13:45, John D. Ament <[hidden email]> a écrit :
> > >> 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?
> > >>
> > >> Nop, liberty does it all wrong. They force setGlobalProvider in the API and this is not needed as any geronimo spec jar or aries shows. This leads to an unsafe user accessible API which is not thread safe and a server destructor :(.
> > >> We need https://github.com/apache/geronimo-specs/pull/9 and at least SPI-Provider header, spifly can be nice too - is used today.
> > >>
> > >>
> > >> And the issue with Java 9 is that you can end up with multiple copies of the packages.
> > >>
> > >> This is not really an issue, no more than today actually since it is the same ones with the same content.
> > >>
> > >>
> > >> On Mon, Jun 4, 2018, 7:42 AM Romain Manni-Bucau <[hidden email]> wrote:
> > >>
> > >>
> > >> Le lun. 4 juin 2018 à 13:36, John D. Ament <[hidden email]> 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 <[hidden email]> 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 |  Blog | Old Blog | Github | LinkedIn | Book
> > >>
> > >>
> > >> Le lun. 4 juin 2018 à 09:52, Mark Struberg <[hidden email]> 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 <[hidden email]>:
> > >>>
> > >>> 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
> > >>
> > >
> >
>

12