On Wed, Jun 6, 2018 at 2:24 PM, Romain Manni-Bucau <[email protected]> wrote:
> 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 ;). > I completely agree! - Ray > > 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) >> > -- *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)
