Re: [jakartaee-tck-dev] Jakarta TCK issues with runclient

[Scott Marlow <smarlow@xxxxxxxxxx>]

On Wed, Mar 20, 2019 at 1:58 PM Scott Highbarger <shighbar@xxxxxxxxxx> wrote:

Scott,
Thanks that does help - it's not too different than the approach we are taking though we have some legacy scripts we are having to recreate the function on etc. That's why I'm surprised at some of the issues we've ran into like the runclient needing the -delieverableDir argument and the TCK's TSScript class getting null on the testArgs as we've not seen those issues before in J2EE 8. We modified the run_jakartaeetck.sh script for now to try to be more aligned in Jakara with the Jakarta TCK/Glassfish approach for now.

I'm curious if your using runclient - did you have to set the -DdelieverableDir, given we can recreate that even with Glassfish I would think it would effect Wildfly as well right?

Sorry, sent that last email before finishing this email.  We are not setting -DdeliverableDir, I can only guess that your hitting a different path in bin/xml/ts.common.props.xml than we are.  From a look at the code, there are a few console prints but maybe not enough.

Do you see "The deliverable currently in use is" in your console?  That message seems to come from https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/bin/xml/ts.common.props.xml#L167, I'm guessing that you are following a different branch in tx.common.props.xml than we are.  When I hit problems with the ant scripts, I like to add more print or echo statements, to give me an idea as to what is going on.  Perhaps you could determine why your not following the same path (e.g. reaching line#167).  

Hope that helps,

Scott

 

I agree on the docker scripts, very interested if we can generalize them enough to apply or use as simple template for different implementations. Another idea we've been looking into related to those scripts is if we can somehow have it spin off multiple docker containers and have each run subsets of the TCK to allow for parallel execution across multiple machines. We've done something like this in the past with the J2EE TCKs to speed up the time required to run all the tests.

Scott E. Highbarger
[shighbar@xxxxxxxxxx]
Advisory Software Engineer
WebSphere Application Server CTS
IBM Software Group
(303) 773-5264




Scott Marlow ---03/20/2019 07:08:03 AM---Hi Scott, In case it helps, for WildFly + Jakarta EE 8 TCK/CTS running, we

From: Scott Marlow <smarlow@xxxxxxxxxx>
To: jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>, Scott Highbarger <shighbar@xxxxxxxxxx>, Lance Andersen <lance.andersen@xxxxxxxxxx>
Date: 03/20/2019 07:08 AM
Subject: Re: [jakartaee-tck-dev] Jakarta TCK issues with runclient

---

Hi Scott,

In case it helps, for WildFly + Jakarta EE 8 TCK/CTS running, we
followed the below steps:

1.  Merged our existing ts.jte settings with the Jakarta EE 8
JTE.settings, there were new properties introduced that needed to also
be specified.

2.  Updated WildFly porting/deployment package (ant script +
configuration files) to use new SPEC API jar names.

3.  Adjusted a number of times to how we obtain the CTS/TCKs (initially
we built it on our own, as well as GlassFish 5.1 builds, now we just
cache a downloaded copy of
https://repo1.maven.org/maven2/org/glassfish/main/distributions/glassfish/5.1.0/glassfish-5.1.0.zip).

For the most part, we are running the Jakarta EE 8 CTS/TCKs, as we did
before, mostly using 'ant runclient', to run each test.

It is good that you are trying to follow the directions for using
RunCTS, someone has to be first it sounds like. :)

I would like to try the docker scripts [1] (not sure if they are
packaged with the various CTS/TCK zips or will be), as they might be
easier to use for recreating CTS/TCK test failures, on developer machines.

Scott

[1] https://github.com/eclipse-ee4j/jakartaee-tck/tree/master/docker