geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <>
Subject Re: [discuss]atinject tck
Date Wed, 11 Aug 2010 19:16:01 GMT
Yep, finally found the OWB email talking about the TCKs (see Q/A #3) -

For build automation, I'd prefer we have copies of these OWB TCK
projects in our own svn in the geronimo/tck area.


On 8/11/10 12:56 PM, Jarek Gawor wrote:
> Donald,
> As Lin pointed out the atinject is a bit different. Both JCDI and Bean
> Validation TCKs can be run in standalone and in-container mode. For
> Geronimo we run them in in-container mode. However, the atinject TCK
> seems to only support the standalone mode. So the question is, is it
> enough to just run the atinject TCK in standalone mode or do we have
> to write some extra code to ensure it runs in in-container mode with
> Geronimo?
> Jarek
> On Wed, Aug 11, 2010 at 12:06 PM, Donald Woods <> wrote:
>> It looks like the same general setup as the BVAL tck, in that it uses
>> the surefire plugin and a suiteXmlFiles which is either provided in the
>> downloaded TCK files or provided locally (which I don't think we can use
>> the open web beans overrides unless we have TCK challenges approved by
>> Oracle.)
>> You should be able to copy the content from
>> over into our geronimo/tck/branches/3.0/ area and make a
>> atinject-tck-runner project similar to the validator-tck-runner.  Jarek
>> already created the required jboss-test-harness-geronimo module to allow
>> the JBoss TCK testharness to start/stop a Geronimo server, so the
>> biggest part of the effort would be mapping the openwebbeans profile
>> from Tomcat over to using Geronimo....
>> Since the JBoss provided TCKs use ASL 2.0, take a look at their website,
>> which usually describes in pretty good detail how to run the TCKs in
>> other app servers.
>> -Donald
>> On 8/11/10 9:30 AM, Lin Sun wrote:
>>> Hi
>>> I have been investigating how to run the JSR 330 tck (also called the
>>> atinject tck), as this is a requirement for Java EE 6 compliance.
>>> I am able to check out the open web bean project and run its atinject
>>> tck from the open web bean project checkout dir, using the atinject
>>> tck runner provided by open web bean   Basically the atinject tck
>>> runner deploys the tck test classes (note it is not an archive) to a
>>> stand-alone test container and the atinect tck tests verifies various
>>> fields/constructors/methods are injected correctly.   The special part
>>> of the atinject tck is that there is no Java EE archive and all tests
>>> are written as junit tests.
>>> My first thought is we could reuse the atinject tck runner from open
>>> web bean project to run the tck, but the concern is that the tests are
>>> only deployed to a stand-alone test container instead of the Geronimo
>>> server.  So I am not sure if that is valid.
>>> My current thoughts are that atinject tck is relatively small and are
>>> junit tests thus it is reasonable to run in a stand-alone test
>>> container.  The JCDI(JSR 299) tck overlaps some of the atinject tck
>>> and should run with the real Application Server like Geronimo.
>>> If we also agree with this approach, I think we can just reuse the
>>> atinject tck runner in open web bean.   WDYT?
>>> Lin
>>> ---------- Forwarded message ----------
>>> From: Kevan Miller <>
>>> Date: Tue, Aug 10, 2010 at 10:43 PM
>>> Subject: Re: JCDI and Bean Validation TCKs
>>> To:
>>> On Jul 21, 2010, at 12:04 AM, Jarek Gawor wrote:
>>>> Ok, it sounds like more people prefer to move these tcks into a public
>>>> svn location.
>>>> So I guess we should create a
>>>> repo and move the tcks
>>>> over. There should be no problem with moving the following modules
>>>> (since it's all Apache licensed stuff):
>>>> 1) jboss-test-harness-geronimo - integration code between jboss test
>>>> harness & geronimo which is used by #2 and #3
>>>> 2) jcdi-testsuite - jcdi tck runner
>>>> 3) validator-testsuite - bean validation tck runner
>>> All,
>>> Please note that the above TCK tests are in our public SVN. Unlike the
>>> mainstream Java EE TCK tests, which we are required to keep private,
>>> these tests are Apache licensed. We can discuss them openly. This
>>> means we have TCK materials in two places (public svn and private
>>> svn). I *much* prefer to have our TCK materials in public svn. So,
>>> although it complicates some things, IMO, we should err on the side of
>>> openness, rather than simplicity...
>>> --kevan

View raw message