Or the osgi point yes (just clarifying cause we hijacked this thread with this point). I would make a lot of sense and hopefully avoid these useless global unsafe static setters in user land. Hopes are strong ;).
Le mer. 6 juin 2018 19:41, Raymond Auge <[email protected]> a écrit : > 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) >
