Also, there is a conversation around an Micro Profile technology review board.
That feels like the level at which we might tackle this issue so that it's considered across MP projects. - Ray On Wed, Jun 6, 2018 at 10:19 AM, Raymond Auge <[email protected]> wrote: > 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 <[email protected]> > 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 <[email protected]> a >> écrit : >> >>> Sounds great. Thanks >>> >>> Le mar. 5 juin 2018 à 09:58, Romain Manni-Bucau <[email protected]> >>> 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 <[email protected]> >>>> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>>> 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 < >>>>>>> [email protected]> 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 <[email protected]> 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 < >>>>>>>>> [email protected]>: >>>>>>>>> > >>>>>>>>> > I know that part but never understood why not using apache parent >>>>>>>>> > >>>>>>>>> > Le lun. 4 juin 2018 22:06, Mark Struberg <[email protected]> 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 < >>>>>>>>> [email protected]>: >>>>>>>>> > > >>>>>>>>> > > 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 <[email protected]> >>>>>>>>> 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 < >>>>>>>>> [email protected]>: >>>>>>>>> > > > >>>>>>>>> > > > 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 < >>>>>>>>> [email protected]>: >>>>>>>>> > > >> >>>>>>>>> > > >> >>>>>>>>> > > >> >>>>>>>>> > > >> Le lun. 4 juin 2018 à 13:45, John D. Ament < >>>>>>>>> [email protected]> 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 < >>>>>>>>> [email protected]> wrote: >>>>>>>>> > > >> >>>>>>>>> > > >> >>>>>>>>> > > >> Le lun. 4 juin 2018 à 13:36, John D. Ament < >>>>>>>>> [email protected]> 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 < >>>>>>>>> [email protected]> wrote: >>>>>>>>> > > >> Well b doesn't solve 3, any way we get karma to do the >>>>>>>>> releases? This would solve that neatly. >>>>>>>>> > > >> >>>>>>>>> > > >> Romain Manni-Bucau >>>>>>>>> > > >> @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book >>>>>>>>> > > >> >>>>>>>>> > > >> >>>>>>>>> > > >> Le lun. 4 juin 2018 à 09:52, Mark Struberg < >>>>>>>>> [email protected]> a écrit : >>>>>>>>> > > >> All fair points, but >>>>>>>>> > > >> >>>>>>>>> > > >> a.) I don't want to host org.eclipse sources at Apache >>>>>>>>> > > >> b.) We can just ship a PR to add those features over there >>>>>>>>> > > >> c.) point 4 should not be the case. >>>>>>>>> > > >> >>>>>>>>> > > >> So I'd vote -1 >>>>>>>>> > > >> >>>>>>>>> > > >> LieGrue, >>>>>>>>> > > >> strub >>>>>>>>> > > >> >>>>>>>>> > > >>> Am 04.06.2018 um 09:09 schrieb Romain Manni-Bucau < >>>>>>>>> [email protected]>: >>>>>>>>> > > >>> >>>>>>>>> > > >>> Hi guys, >>>>>>>>> > > >>> >>>>>>>>> > > >>> we have 4 MP implementations I think (failsafe, config, >>>>>>>>> jwt-auth and opentracing) and 2 of them reused eclipse api jar and 2 >>>>>>>>> uses a >>>>>>>>> geronimo flavor. >>>>>>>>> > > >>> >>>>>>>>> > > >>> I'd like us to discuss which flavor we want to align all >>>>>>>>> of them. >>>>>>>>> > > >>> >>>>>>>>> > > >>> The fact to reuse the API reduces the code we hosts which >>>>>>>>> is not bad but has these drawbacks: >>>>>>>>> > > >>> >>>>>>>>> > > >>> 1. when a loader is involved we can't enhance it for our >>>>>>>>> consumers (like aries) to be compatible with other mecanism than >>>>>>>>> plain java >>>>>>>>> standalone (+ standard java(ee) mecanism like lib/<spec>.properties >>>>>>>>> which >>>>>>>>> is sometimes used in users land) >>>>>>>>> > > >>> 2. geronimo always provided a good entry point to be OSGi >>>>>>>>> friendly. I saw that some MP@eclipse jar provided some OSGi work >>>>>>>>> but they rely on a dependency we don't want in all not OSGi apps + >>>>>>>>> they >>>>>>>>> don't embrace what our consumers do (spifly+javacontract we will >>>>>>>>> merge soon) >>>>>>>>> > > >>> 3. it is very slow to have an eclipse release (opentracing >>>>>>>>> and jwt auth were a pain and even led to use tck in snapshot to >>>>>>>>> launch the >>>>>>>>> release after having waited weeks) >>>>>>>>> > > >>> 4. if there is some default hardcoded (dont think it is >>>>>>>>> the case yet but it can likely be appended in 1 to be consistent with >>>>>>>>> the >>>>>>>>> javaee/jakartaee behavior) then we will want to put our default and >>>>>>>>> not the >>>>>>>>> RI one >>>>>>>>> > > >>> >>>>>>>>> > > >>> At the end the cost to have the spec jar is almost nothing >>>>>>>>> to not say really nothing so I'm in favor of ensuring we always host >>>>>>>>> it. >>>>>>>>> > > >>> >>>>>>>>> > > >>> Romain Manni-Bucau >>>>>>>>> > > >>> @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book >>>>>>>>> > > >> >>>>>>>>> > > > >>>>>>>>> > > >>>>>>>>> > >>>>>>>>> >>>>>>>>> > > > -- > *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) > -- *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)
