geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <>
Subject Re: JCDI and Bean Validation TCKs
Date Wed, 11 Aug 2010 20:56:42 GMT
The BVAL and JCDI builds have now been updated to allow extracting
Geronimo assemblies into the target directory for automated testing.

mvn test -Pincontainer,geronimo-assembly -DassemblyId=tomcat7-javaee6

Note, that the assemblyIds are different from the ones defined in the
parent server POM, as we have to pass in the fully qualified directory
to the server based on the provided assemblyId.


On 7/21/10 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
> But I also would like to move the following two modules:
> 4) jaxb-testsuite - jaxb tck runner
> 5) stax-testsuite - stax tck runner
> #4 and #5 are basically just pom files that download the right
> Geronimo dependencies and unix shell scripts that run the given tck in
> batch mode. The actual tck must be downloaded/setup separately. They
> do however contain a JavaTest configuration file that configures the
> tck. So I'm not 100% sure if these modules can be moved because of
> that config file.
> Also, should these modules move to
> or to
> to mimic
> the setup we have in geronimo-tck repo?
> If there are no major objections to this plan I'll start working on it tomorrow.
> Jarek
> On Tue, Jul 20, 2010 at 1:19 PM, Kevan Miller <> wrote:
>> On Jul 20, 2010, at 3:05 AM, David Jencks wrote:
>>> On Jul 19, 2010, at 10:37 PM, Jarek Gawor wrote:
>>>> My main concern is that if we move the JCDI and Bean Validation
>>>> porting code to public svn location then we will effectively have two
>>>> mailing lists for discussing tck issues, two jira places for filing
>>>> and tracking tck challenges, possibly two wiki places for tck info,
>>>> etc. And we will have to be extra careful to discuss a given tck
>>>> problem on the right list... and sooner or later somebody will use the
>>>> wrong list.
>>>> Yes, it would be nice to have this stuff in open but I'm just
>>>> wondering how much headache it will be to keep track of it all and
>>>> maintain it.
>>> I think its going to be significantly harder to maintain out in the open and
there is much more likelyhood of slips in talking about NDA stuff on public lists, but I don't
think we have any good argument for keeping the harnesses for these tcks in the private svn.
 IMO ideally all the tcks would be public so I feel a bit morally obligated to put anything
that can be public, in public.
>> Good discussion. My preference would be to err on the side of openness. So, would
prefer to see the harnesses in public svn and documentation on public Wiki. I think we can
maintain any actual TCK challenges using TCK Jira and TCK mailing list (i.e. use the existing
mechanisms for ASF communications with Oracle). Would assume that most challenges would have
been preceded by a public discussion...
>> If we mess up and accidentally reveal some private TCK information, then so be it.
Accidents have (and will) happen. In my experience, you can find a lot more TCK private information
on Sun/Oracle's bug reports then we've ever revealed. Not saying we should ignore the issue.
Just saying we shouldn't lose much sleep over it, either...
>> -- kevan

View raw message