jsr303-tck v1.0.5.GA came out today. This question is still open. I remind the group that one codebase *cannot* simultaneously pass a TCK < v1.0.5 and one >= v1.0.5.
Matt On Mon, Jan 24, 2011 at 10:35 AM, Matt Benson <[email protected]> wrote: > I feel like we're going in circles, but I feel like the clouds may be > breaking since you've mentioned "as part of our Java EE 6 projects." Am I to > understand that this is the context in which "the TCK provided by Oracle" > manages to trump that provided by the spec lead? My next question is then > whether we have any recourse to seek an updated TCK from Oracle? > > Matt > > On Jan 23, 2011, at 1:00 PM, Donald Woods wrote: > >> Currently, 1.0.3.GA is the latest version we have from Oracle for the >> ASF to use as part of our Java EE 6 projects. Until we get an updated >> version, we need to maintain compliance with that level. We could >> create a 1.0.x maintenance branch for the 1.0.3 TCK and then upgrade >> trunk to >= 1.0.5. >> >> -Donald >> >> >> On 1/14/11 4:39 PM, Mark Struberg wrote: >>> imo we should always aim to pass the latest available (and known good) TCK. >>> >>> Please note that there are often some known issues _inside_ some TCK due to >>> over-interpretation of the spec wording, differences between the spec >>> wording and the spec-published javadoc (which has higher prio), etc. >>> >>> So taking the latest available (and reporting any problems back to the EG) >>> is always a good thing imo. >>> >>> LieGrue, >>> strub >>> >>> --- On Fri, 1/14/11, Matt Benson <[email protected]> wrote: >>> >>>> From: Matt Benson <[email protected]> >>>> Subject: Re: svn commit: r1002445 - /incubator/bval/trunk/bval-tck/pom.xml >>>> To: [email protected] >>>> Date: Friday, January 14, 2011, 9:12 PM >>>> Resurrecting this thread: >>>> While it may be possible, as David suggests, to >>>> manage different TCK >>>> versions with Maven profiles, the point will become moot >>>> after the >>>> release of the 1.0.5 version of the >>>> TCK: due to >>>> http://opensource.atlassian.com/projects/hibernate/browse/BVTCK-12 >>>> a >>>> JSR303 implementation will realistically be able to pass a >>>> TCK < >>>> v1.0.5 or >= 1.0.5, but not both. My personal >>>> preference is to make >>>> Apache Bean Validation conform to the spec and thus the >>>> later version >>>> of the TCK. Can we take a basic poll as to the >>>> general preference of >>>> the team? >>>> >>>> Matt >>>> >>>> On 10/4/10, Gerhard <[email protected]> >>>> wrote: >>>>> i agree with mark. >>>>> >>>>> regards, >>>>> gerhard >>>>> >>>>> http://www.irian.at >>>>> >>>>> Your JSF powerhouse - >>>>> JSF Consulting, Development and >>>>> Courses in English and German >>>>> >>>>> Professional Support for Apache MyFaces >>>>> >>>>> >>>>> >>>>> 2010/10/2 Mark Struberg <[email protected]> >>>>> >>>>>> Oki, sorry for not being specific enough. I'll try >>>> to rephrase what I >>>>>> mean: >>>>>> >>>>>> If we pass the open JSR-303 TCK, then we can claim >>>> to be 'JSR-303 >>>>>> compatible' and 'successfully passed the JSR-303 >>>> TCK'. >>>>>> >>>>>> But for calling us 'Sun/Oracle TCK JSR-303 >>>> certified' then we would of >>>>>> course need to go the official oracle route. >>>>>> >>>>>> makes sense? >>>>>> >>>>>> LieGrue, >>>>>> strub >>>>>> >>>>>> --- On Fri, 10/1/10, David Jencks <[email protected]> >>>> wrote: >>>>>> >>>>>>> From: David Jencks <[email protected]> >>>>>>> Subject: Re: svn commit: r1002445 - >>>>>> /incubator/bval/trunk/bval-tck/pom.xml >>>>>>> To: [email protected] >>>>>>> Date: Friday, October 1, 2010, 11:04 PM >>>>>>> >>>>>>> On Oct 1, 2010, at 3:22 PM, Mark Struberg >>>> wrote: >>>>>>> >>>>>>>> isn't the JSR-303 ASL-2 licensed [1]? >>>>>>>> >>>>>>>> So I don't think we need to wait for any >>>> special >>>>>>> Oracle agreement! >>>>>>>> >>>>>>>> If you like, then I could ping Emmanuel, >>>> but usually >>>>>>> the latest TCK is available in the jboss >>>> maven repo. >>>>>>> >>>>>>> I think it makes sense to run both for >>>> now. Since its >>>>>>> a jcp managed spec, to claim compliance, I >>>> think we have >>>>>>> to run the tck from the official jcp >>>> channels, which, >>>>>>> unless we hear something different from >>>> Oracle, is Oracle. >>>>>>> >>>>>>> Can we put the choice of tck in a couple >>>> profiles? >>>>>>> >>>>>>> david jencks >>>>>>> >>>>>>>> >>>>>>>> LieGrue, >>>>>>>> strub >>>>>>>> >>>>>>>> >>>>>>>> [1] >>>>>> http://docs.jboss.org/hibernate/stable/beanvalidation/tck/reference/html_single/ >>>>>>>> >>>>>>>> >>>>>>>> --- On Fri, 10/1/10, Donald Woods <[email protected]> >>>>>>> wrote: >>>>>>>> >>>>>>>>> From: Donald Woods <[email protected]> >>>>>>>>> Subject: Re: svn commit: r1002445 - >>>>>>> /incubator/bval/trunk/bval-tck/pom.xml >>>>>>>>> To: [email protected] >>>>>>>>> Date: Friday, October 1, 2010, 10:14 >>>> PM >>>>>>>>> Hopefully Kevan will chime in too, >>>>>>>>> but it's my understanding that we >>>>>>>>> have to pass the BVAL TCK as >>>> provided by Oracle >>>>>>> under the >>>>>>>>> Oracle/ASF NDA >>>>>>>>> in order to claim we're >>>> certified.... >>>>>>>>> >>>>>>>>> During daily testing, I use the TCK >>>> files >>>>>>> downloaded from >>>>>>>>> the JBoss >>>>>>>>> repo. Before we release the >>>> Apache BVAL >>>>>>> artifacts, I >>>>>>>>> always run the >>>>>>>>> release artifacts against the TCK as >>>> provided by >>>>>>> Oracle. >>>>>>>>> >>>>>>>>> >>>>>>>>> -Donald >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/1/10 2:14 PM, Matt Benson >>>> wrote: >>>>>>>>>> >>>>>>>>>> On Oct 1, 2010, at 12:26 PM, >>>> Donald Woods >>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> The current BVAL TCK from >>>> Oracle that we >>>>>>> have to >>>>>>>>> certify with is >>>>>>>>>>> >>>> jsr303-tck-1.0.3.GA-dist.zip, which uses >>>>>>> the >>>>>>>>> 1.0.3.GA level of the API. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Apparently I am not fully >>>> cognizant of the >>>>>>> TCK-related >>>>>>>>> aspects of the JCP process. >>>>>> https://cwiki.apache.org/confluence/display/BeanValidation/JSR303+TCK >>>>>>>>> says: >>>>>>>>>> TBD - Need to ask >>>> if we must use >>>>>>> the >>>>>>>>> Sun/Oracle provided TCK for final >>>> certification >>>>>>> testing.... >>>>>>>>>> >>>>>>>>>> Have there been further >>>> developments in this >>>>>>>>> regard? It was my impression >>>> that a spec >>>>>>>>> implementation must simply pass the >>>> TCK supplied >>>>>>> by the spec >>>>>>>>> lead. I had no idea there was >>>> both an Oracle >>>>>>> TCK and a >>>>>>>>> JBoss TCK. Where I can learn >>>> more about >>>>>>> certification >>>>>>>>> as it applies to this JSR and our >>>> efforts? >>>>>>>>>> >>>>>>>>>>> If you look at the TCK that >>>> gets >>>>>>> downloaded during >>>>>>>>> the TCK build, those >>>>>>>>>>> files also download the >>>> 1.0.3.GA level of >>>>>>> the API >>>>>>>>> and matches the >>>>>>>>>>> distribution as provided by >>>> Oracle. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I honestly don't see where you >>>> see this. >>>>>>> I don't >>>>>>>>> see any indication of it in >>>>>>> bval-tck/target/dependency/lib >>>>>>>>> or in the tck POM. >>>>>>>>>> >>>>>>>>>>> I haven't looked at the >>>> 1.0.4 level yet, >>>>>>> so is >>>>>>>>> there something in there >>>>>>>>>>> that we need? What >>>> changes were >>>>>>> introduced? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> My lack of understanding of the >>>> issues simply >>>>>>> led me >>>>>>>>> to believe that the more recent >>>> release of the >>>>>>> spec we could >>>>>>>>> pass, the better. In >>>> particular I had hoped >>>>>>> that there >>>>>>>>> might be a difference in TCK >>>> versions with regard >>>>>>> to my >>>>>>>>> allegations on the incorrectness of >>>> the RI >>>>>>> implementation of >>>>>>>>> the Path interface. >>>>>>>>>> >>>>>>>>>> -Matt >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -Donald >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 10/1/10 12:37 PM, Matt >>>> Benson wrote: >>>>>>>>>>>> >>>>>>>>>>>> On Oct 1, 2010, at 11:18 >>>> AM, Donald >>>>>>> Woods >>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Matt, the latest TCK >>>> drop from >>>>>>> Oracle is >>>>>>>>> 1.0.3, so I'd rather not move >>>>>>>>>>>>> up until we have a >>>> newer TCK level >>>>>>> that >>>>>>>>> matches..... >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I'm fine with whatever >>>> the community >>>>>>> decides, >>>>>>>>> of course, but can you explain the >>>> above? >>>>>>> I'm afraid I >>>>>>>>> don't understand... >>>>>>>>>>>> >>>>>>>>>>>> -Matt >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -Donald >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 9/28/10 9:53 PM, >>>> [email protected] >>>>>>>>> wrote: >>>>>>>>>>>>>> Author: mbenson >>>>>>>>>>>>>> Date: Wed Sep 29 >>>> 01:53:36 >>>>>>> 2010 >>>>>>>>>>>>>> New Revision: >>>> 1002445 >>>>>>>>>>>>>> >>>>>>>>>>>>>> URL: http://svn.apache.org/viewvc?rev=1002445&view=rev >>>>>>>>>>>>>> Log: >>>>>>>>>>>>>> upgrade to tck >>>> version >>>>>>> 1.0.4.GA >>>>>>>>>>>>>> >>>>>>>>>>>>>> Modified: >>>>>>>>>>>>>> >>>>>>> incubator/bval/trunk/bval-tck/pom.xml >>>>>>>>>>>>>> >>>>>>>>>>>>>> Modified: >>>>>>>>> >>>> incubator/bval/trunk/bval-tck/pom.xml >>>>>>>>>>>>>> URL: >>>>>> http://svn.apache.org/viewvc/incubator/bval/trunk/bval-tck/pom.xml?rev=1002445&r1=1002444&r2=1002445&view=diff >>>>>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>> ============================================================================== >>>>>>>>>>>>>> --- >>>>>>>>> >>>> incubator/bval/trunk/bval-tck/pom.xml (original) >>>>>>>>>>>>>> +++ >>>>>>>>> >>>> incubator/bval/trunk/bval-tck/pom.xml Wed Sep 29 >>>>>>> 01:53:36 >>>>>>>>> 2010 >>>>>>>>>>>>>> @@ -92,7 +92,7 >>>> @@ >>>>>>>>>>>>>> >>>>>>> >>>>>>>>> >>>> <dependency> >>>>>>>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>> <groupId>org.hibernate.jsr303.tck</groupId> >>>>>>>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>>>> >>>> <artifactId>jsr303-tck</artifactId> >>>>>>>>>>>>>> - >>>>>>> >>>>>>>>> >>>>>>>>> >>>> <version>1.0.3.GA</version> >>>>>>>>>>>>>> + >>>>>>> >>>>>>>>> >>>>>>>>> >>>> <version>1.0.4.GA</version> >>>>>>>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> </dependency> >>>>>>>>>>>>>> >>>>>>> >>>>>>>>> >>>> <dependency> >>>>>>>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>> <groupId>org.jboss.test-harness</groupId> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >>> >>> > >
