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 >>>>>>> > > >> >>>>>>> > > > >>>>>>> > > >>>>>>> > >>>>>>> >>>>>>>
