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. -Donald 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 > https://svn.apache.org/repos/asf/geronimo/tck 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 > https://svn.apache.org/repos/asf/geronimo/tck/trunk or to > https://svn.apache.org/repos/asf/geronimo/tck/branches/3.0 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 <kevan.mil...@gmail.com> 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 >
