It looks like the SQL is not the real issue here - although it is a bit confusing because the select statements look ok to me.
However, after same additional digging / fiddling arround, I am at a point, there the JVM for the tests does not startup due to an StackOverflowError [1]. I tried remote debugging via "-dj" but have no glue why I am running to this StackOverflowError during the "ant.java(...)" call in the related groovy command. I bet, that I miss a little detail - so happy to any additional input ;) Gruß R [1] https://gist.github.com/rzo1/0af90723dc0c6689a6f7d7bae9d2e8da Am Dienstag, dem 26.04.2022 um 09:59 +0000 schrieb Zowalla, Richard: > Hi, > > I changed the script pointing to the released ee9.1 tck now and > updated > the README accordingly. If the instructions are followed carefully, > it > will lead to a fresh installation. > > In the process, I noticed, that Glassfish 6.0.0 isn't available > anymore > and is replaced by 6.2.5 - JL mentioned on Slack, that 6.2.5 should > also work. > > I think, that we do not really need a public git repository. Setting > it > up with the script is really straight forward. However, putting the > TCK > installation into a local git repository makes totally sense in order > to avoid delete / unpack cycles due to the modifications on the > installation, if the TCK is run. > > I added some instructions in the README. > > Currently, I am struggling with > > [ERROR] java.sql.SQLSyntaxErrorException: Syntax error: Encountered > "Simple_Select_Query" at line 1, column 1. > [INFO] 1130 of 1307 SQL statements executed successfully > > when running > > rm -rf target/ && ./runtests -Dhttps.protocols=TLSv1.1,TLSv1.2 --ee91 > --env -nc -c -U -w tomee-plume > com.sun.ts.tests.ejb30.lite.appexception.singleton.annotated.Client > > as the initial setup of the derby database seem to fail - don't have > much ideas but using the search engine of trust I found an entry, > that > this also happened on a tck.work build long time ago. > > I guess, that I am just missing a little thing to fix it for my > setup. > > Currently, the TCK runs will fail anyway as we need to fix java mail > first but getting the same exception / outcome as JL would be > beneficial as it would prove, that the setup works and others can > simply replicate - if this work, I will re-evaluate the instructions > for debugging ;) > > > Gruß & thanks > Richard > > > Am Montag, dem 25.04.2022 um 14:13 -0700 schrieb David Blevins: > > Thanks for digging into this, Richard! > > > > Agree with your prior statements about updating the README, > > branching > > for TomEE 8 and making TomEE 9 the master branch in the tomee-tck > > project. > > > > > > > On Apr 24, 2022, at 11:14 PM, Zowalla, Richard < > > > richard.zowa...@hs-heilbronn.de> wrote: > > > > > > Ok, I found it: > > > > > > - > > > https://lists.apache.org/thread/sfbvz76c527wojym71csv72k8j2qrrg7 > > > > > > If we adjust the script to target the (released) ee9.1 tck > > > (instead > > > of > > > the snapshots), it will certainly help. (This was the script I > > > had > > > in > > > mint) > > > > Agree. Maybe it needs a new name as well so it's more clear that > > it > > can be used to create a fresh setup. > > > > > But while searching the list archive, I also found this post on > > > happy > > > TCK work: > > > > > > - > > > https://lists.apache.org/thread/vgthyd8d7rww2p398r9swx8y37mwxf9c > > > > > > Sadly the setup images from IntelliJ IDEA are gone (maybe you > > > have > > > them > > > somewhere, David?). > > > > Unfortunately, I don't have those images anymore. We can maybe > > describe the menu steps instead of showing images. Getting that on > > the website in the developer area would be good. > > > > > Perhaps we should provide a similar jakartaeetck-9.x installation > > > via a > > > Git repository? > > > > > > Then we could adjust the "update" script and make it an "install" > > > script. > > > > The trick here is licensing of the TCK source code, which is > > EPL. Here's the source of truth on "is this license ok" questions: > > > > - > > https://www.apache.org/legal/resolved.html#weak-copyleft-licenses > > > > Effectively, we can use EPL in binary form. In source form it's ok > > in small amounts where it generally can't be avoided. An entire > > repository of EPL source code living under > > https://github.com/apache/ > > is likely not ok. > > > > It doesn't mean the idea is shot, but it does mean that repo would > > have to live outside the Apache org in github. > > > > > That would ease the necessary setup steps. Wdyt? > > > > Definitely agree it's a great idea. Perhaps we could create an org > > of our own? > > > > > > -David > >
smime.p7s
Description: S/MIME cryptographic signature
