Hi all, as many of you know already, Weld 2.2 is going to be the reference implementation of the upcoming maintenance release of the CDI specification. CDI is an EE specification. That implies that the CDI TCK which validates a CDI implementation has to be run against an EE container not just the CDI implementation itself (e.g. Weld Core). So far, both existing releases of CDI (1.0 and 1.1) were always part of a major Java EE release (6 and 7). It therefore made sense to require the CDI RI to run as part of the GlassFish application server since GlassFish is the RI for each recent Java EE version. However, with CDI 1.2 the situation is different. Since CDI 1.2 is not part of a major Java EE release, we see no reason to require the CDI 1.2 RI to run specifically on GlassFish at the end of the maintenance release window. Instead, any Java EE 7 certified application server should be suitable. Therefore, we are going to use WildFly (http://wildfly.org/) as the runtime for CDI 1.2 RI and TCK. Note that this by no means defines which Java EE servers will or will not support CDI 1.2. This proposal only defines which Java EE server will be used at the end of the CDI 1.2 MR effort to validate the RI and the TCK. Regards, Jozef _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

Romain, I think what Jozef meant is that JCP MR process doesn't force us to provide Glassfish integration on the scope of the MR. Right now Glassfish integrates Weld 2.0.0.SP1 and Oracle has a nightly build with Weld 2.0.5 [1]. Working on Weld 2.1 and 2.2 integration could be quite time consuming especially if Glassfish people are not available to help us on that. So there are too many parameters we don't control to take the risk of adding this constraint in our 60 days MR. What we control on JBoss side is Wildfly integration so that's why Jozef made this proposal. Off course we'll do the necessary and help GF developers to integrates Weld 2.2 in GF but taking it in our agenda is quite risky. Now that can be discussed if a GF developer is reading this message and raise the Hand... Antoine [1] https://blogs.oracle.com/theaquarium/entry/using_updated_release_of_jersey Le 28 janv. 2014 à 13:36, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; a écrit : > Hi > > I think it should still run on GlassFish to try to ensure > compatibility with previous version (at least). We all know > integration is where the most issues are. > > wdyt? > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > > 2014-01-28 Jozef Hartinger <jharting(a)redhat.com&gt;: >> Hi all, >> >> as many of you know already, Weld 2.2 is going to be the reference >> implementation of the upcoming maintenance release of the CDI specification. >> >> CDI is an EE specification. That implies that the CDI TCK which >> validates a CDI implementation has to be run against an EE container not >> just the CDI implementation itself (e.g. Weld Core). >> >> So far, both existing releases of CDI (1.0 and 1.1) were always part of >> a major Java EE release (6 and 7). It therefore made sense to require >> the CDI RI to run as part of the GlassFish application server since >> GlassFish is the RI for each recent Java EE version. >> >> However, with CDI 1.2 the situation is different. Since CDI 1.2 is not >> part of a major Java EE release, we see no reason to require the CDI 1.2 >> RI to run specifically on GlassFish at the end of the maintenance >> release window. Instead, any Java EE 7 certified application server >> should be suitable. Therefore, we are going to use WildFly >> (http://wildfly.org/) as the runtime for CDI 1.2 RI and TCK. >> >> Note that this by no means defines which Java EE servers will or will >> not support CDI 1.2. This proposal only defines which Java EE server >> will be used at the end of the CDI 1.2 MR effort to validate the RI and >> the TCK. >> >> Regards, >> >> Jozef >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev

No problem Romain, To be honest I'm far more interested by putting work effort on having the TCK running on your coming OWB release in TomEE than validating twice Weld on WF and GF. Off course this comment is totally outside MR scope ;). Antoine Le 28 janv. 2014 à 14:34, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; a écrit : > I got the point but I really think we shoudln't change the RI default > Integration before 2.0. That said you are right if GF doesn't care and > is not able to follow the release just forget my comment. > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > > 2014-01-28 Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt;: >> Romain, >> >> I think what Jozef meant is that JCP MR process doesn't force us to provide Glassfish integration on the scope of the MR. Right now Glassfish integrates Weld 2.0.0.SP1 and Oracle has a nightly build with Weld 2.0.5 [1]. Working on Weld 2.1 and 2.2 integration could be quite time consuming especially if Glassfish people are not available to help us on that. >> So there are too many parameters we don't control to take the risk of adding this constraint in our 60 days MR. What we control on JBoss side is Wildfly integration so that's why Jozef made this proposal. >> Off course we'll do the necessary and help GF developers to integrates Weld 2.2 in GF but taking it in our agenda is quite risky. >> Now that can be discussed if a GF developer is reading this message and raise the Hand... >> >> Antoine >> >> >> [1] https://blogs.oracle.com/theaquarium/entry/using_updated_release_of_jersey >> >> >> Le 28 janv. 2014 à 13:36, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; a écrit : >> >>> Hi >>> >>> I think it should still run on GlassFish to try to ensure >>> compatibility with previous version (at least). We all know >>> integration is where the most issues are. >>> >>> wdyt? >>> Romain Manni-Bucau >>> Twitter: @rmannibucau >>> Blog: http://rmannibucau.wordpress.com/ >>> LinkedIn: http://fr.linkedin.com/in/rmannibucau >>> Github: https://github.com/rmannibucau >>> >>> >>> >>> 2014-01-28 Jozef Hartinger <jharting(a)redhat.com&gt;: >>>> Hi all, >>>> >>>> as many of you know already, Weld 2.2 is going to be the reference >>>> implementation of the upcoming maintenance release of the CDI specification. >>>> >>>> CDI is an EE specification. That implies that the CDI TCK which >>>> validates a CDI implementation has to be run against an EE container not >>>> just the CDI implementation itself (e.g. Weld Core). >>>> >>>> So far, both existing releases of CDI (1.0 and 1.1) were always part of >>>> a major Java EE release (6 and 7). It therefore made sense to require >>>> the CDI RI to run as part of the GlassFish application server since >>>> GlassFish is the RI for each recent Java EE version. >>>> >>>> However, with CDI 1.2 the situation is different. Since CDI 1.2 is not >>>> part of a major Java EE release, we see no reason to require the CDI 1.2 >>>> RI to run specifically on GlassFish at the end of the maintenance >>>> release window. Instead, any Java EE 7 certified application server >>>> should be suitable. Therefore, we are going to use WildFly >>>> (http://wildfly.org/) as the runtime for CDI 1.2 RI and TCK. >>>> >>>> Note that this by no means defines which Java EE servers will or will >>>> not support CDI 1.2. This proposal only defines which Java EE server >>>> will be used at the end of the CDI 1.2 MR effort to validate the RI and >>>> the TCK. >>>> >>>> Regards, >>>> >>>> Jozef >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>

It's not a question of whether we run or GlassFish or not but rather when. On 01/28/2014 01:36 PM, Romain Manni-Bucau wrote: > Hi > > I think it should still run on GlassFish to try to ensure > compatibility with previous version (at least). We all know > integration is where the most issues are. > > wdyt? > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev