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