BTW, would it be possible to encourage the cdi expert group to specify the correct osgi package versions for the spec packages? I think the 1.0 spec getting 1.0 package versions is pretty easy to agree on, I'd like it if the 1.1 package versions were both semantically correct and specified in the spec itself.
thanks david jencks On Oct 5, 2011, at 1:39 PM, David Jencks wrote: > I created GERONIMO-6182 and set up a geronimo specs project for the cdi 1.1 > spec by copying the 1.0 spec project. > > https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-jcdi_1.1_spec > > I'll do my best to apply patches attached to the jira promptly. > > thanks > david jencks > > On Oct 5, 2011, at 12:46 AM, Mark Struberg wrote: > >> Hi folks! >> >> While working on OWB-589 yesterday, I realized that we cannot use our old >> 1.0 TCK for new CDI-1.1 features anymore. >> While OWB always was more like a CDI-1.1 container than 1.0 ('global' >> interceptors, no BDA), there are still some changes which are notable. >> >> *) CDI-1.1 adds a few annotations, so firstly we need to add those to a new >> geronimo-specs-jcdi-1.1. Dblevins, Djencks, how do we do this best? Should I >> just ship patches? >> *) The CDI-1.1 TCK is now based on arquillian -> we have to change our tck >> integration >> *) we can finally remove all the BDA handling stuff with the public static >> ThreadLocals (at least a few of them). This got removed from the spec >> >> >> From a users perspective CDI-1.1 is pretty much backward compatible. From >> the TCK perspective, CDI-1.1 removed some unnecessary restrictions, e.g in >> the Serialization check area. >> >> How do we continue with our release planing? >> >> There are a few possible options: >> >> a.) 1.1.2-SNAPSHOT (as all versions since 1.0.0-alpha1) already contains a >> few CDI-1.1 parts, so should we just continue? >> >> b.) Since Geronimo, TomEE and WebSphere use OWB as CDI-1.0 container, should >> we now release a 1.1.2 version and create a maintenance branch for it? This >> would mean that the 1.1.x branch would not get much love from us anymore, >> and we will focus on 1.2.0-SNAPSHOT >> >> c.) Should we just branch 1.1.x now (without a release) and move our trunk >> to version 1.2.0-SNAPSHOT, then actively maintain both? (That would mean >> that someone else than I must handle the maintenance branch). >> >> LieGrue, >> strub >
