I think it would be great if many of us could upvote the issue created by Romain:
https://github.com/eclipse/microprofile-jwt-auth/issues/95 I have put in my 2 cents worth on it. - Ray On Wed, Jun 6, 2018 at 7:51 AM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > Ok guys, seems we have a consensus to drop the G api flavors, any idea > where to hit MP to make them handle it as a whole and not per spec? Then I > guess we can do our housekeeping and move forward on more important topics > :). > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > > Le mar. 5 juin 2018 à 14:15, Jean-Louis MONTEIRO <jeano...@gmail.com> a > écrit : > >> Sounds great. Thanks >> >> Le mar. 5 juin 2018 à 09:58, Romain Manni-Bucau <rmannibu...@gmail.com> >> 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 <https://twitter.com/rmannibucau> | Blog >>> <https://rmannibucau.metawerx.net/> | Old Blog >>> <http://rmannibucau.wordpress.com> | Github >>> <https://github.com/rmannibucau> | LinkedIn >>> <https://www.linkedin.com/in/rmannibucau> | Book >>> <https://www.packtpub.com/application-development/java-ee-8-high-performance> >>> >>> >>> Le mar. 5 juin 2018 à 09:55, Jean-Louis MONTEIRO <jeano...@gmail.com> 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 <rmannibu...@gmail.com> >>>> 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 <https://twitter.com/rmannibucau> | Blog >>>>> <https://rmannibucau.metawerx.net/> | Old Blog >>>>> <http://rmannibucau.wordpress.com> | Github >>>>> <https://github.com/rmannibucau> | LinkedIn >>>>> <https://www.linkedin.com/in/rmannibucau> | Book >>>>> <https://www.packtpub.com/application-development/java-ee-8-high-performance> >>>>> >>>>> >>>>> Le mar. 5 juin 2018 à 09:14, Jean-Louis MONTEIRO <jeano...@gmail.com> >>>>> 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 < >>>>>> rmannibu...@gmail.com> a écrit : >>>>>> >>>>>>> So not needed if we use apache parent pby - this was my point >>>>>>> >>>>>>> >>>>>>> Romain Manni-Bucau >>>>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog >>>>>>> <http://rmannibucau.wordpress.com> | Github >>>>>>> <https://github.com/rmannibucau> | LinkedIn >>>>>>> <https://www.linkedin.com/in/rmannibucau> | Book >>>>>>> <https://www.packtpub.com/application-development/java-ee-8-high-performance> >>>>>>> >>>>>>> >>>>>>> Le mar. 5 juin 2018 à 08:41, Mark Struberg <strub...@yahoo.de> 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 < >>>>>>>> rmannibu...@gmail.com>: >>>>>>>> > >>>>>>>> > I know that part but never understood why not using apache parent >>>>>>>> > >>>>>>>> > Le lun. 4 juin 2018 22:06, Mark Struberg <strub...@yahoo.de> 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 < >>>>>>>> rmannibu...@gmail.com>: >>>>>>>> > > >>>>>>>> > > 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 <strub...@yahoo.de> >>>>>>>> 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 < >>>>>>>> strub...@yahoo.de>: >>>>>>>> > > > >>>>>>>> > > > 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 < >>>>>>>> rmannibu...@gmail.com>: >>>>>>>> > > >> >>>>>>>> > > >> >>>>>>>> > > >> >>>>>>>> > > >> Le lun. 4 juin 2018 à 13:45, John D. Ament < >>>>>>>> johndam...@apache.org> 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 < >>>>>>>> rmannibu...@gmail.com> wrote: >>>>>>>> > > >> >>>>>>>> > > >> >>>>>>>> > > >> Le lun. 4 juin 2018 à 13:36, John D. Ament < >>>>>>>> johndam...@apache.org> 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 < >>>>>>>> rmannibu...@gmail.com> 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 < >>>>>>>> strub...@yahoo.de> 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 < >>>>>>>> rmannibu...@gmail.com>: >>>>>>>> > > >>> >>>>>>>> > > >>> 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 >>>>>>>> > > >> >>>>>>>> > > > >>>>>>>> > > >>>>>>>> > >>>>>>>> >>>>>>>> -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
