liberty-gradle-plugin 3.8 TestKit failure on com.ibm.websphere.ras.DataFormatHelper ClassNotFound #867
Comments
|
@sreich Very interesting indeed. What version of Java are you using? |
|
So the @jjiwooLim Sarah, any ideas on this one? |
|
@sreich As a workaround, you may be able to set |
|
@sreich Could you try cleaning the Gradle cache or restart the Gradle daemon? |
|
@jjiwooLim yep, already did before posting, did it a few more times since then too, problem is reproducible on my machine and our CI agents as well @cherylking Gradle's executing under JDK 11, it seems like logs indicate that was what it built with too (just to double-confirm) I added the verify skip which after that, I can see the logs indicate that liberty is choosing to skip verification, but it still has the same ClassNotFound. Do we know what is the expected origin of that class it can't find? I've attached the full --info dump here, it's a bit large |
Well darn...was hoping that would bypass this problem. Having looked at the latest log, this is the current stacktrace: @jjiwooLim ^^ |
|
@sreich The class that is not found is located in the Also, does this |
|
@sreich Please try the |
|
I work with Shaun. I've attached a project that reproduces the issue. We have worked around it on our end by simply splitting a test that ran on the same project 3 times (with slightly different configurations) to each have its own test case. But basically, you have to have debug running in the testkit run, do libertyCreate on the same project twice, then switch to another project and run it -- all in the same JVM run. Kind of a corner case, I guess. |
|
@timdvail Thanks for the details and the project to recreate. Were you able to try the snapshot to see if it fixed the issue? |
|
I tried the snapshot, same test failure when I bumped the version in the libs.versions.toml file under gradle folder and pointed to sonar snapshot repo as per README. |
@timdvail @sreich Ok, thanks for trying. I am glad you have a workaround. Is it okay if this waits until January for further debugging? We are trying to wrap up quite a bit before holiday vacations start kicking in. |
|
It is fine to wait until after holiday. Thanks! |
|
All you have to do is run gradle clean build in that project. I just tried it on my personal laptop (which is Linux), I did find that the gradlew script incorrectly had Windows carriage returns in it which caused issues for running it. But once I stripped out those carriage returns, running: The build will fail in the test step -- test is 'should run successfully every time'. The failed test exhibits the exact issue that is brought up in this issue. You can always try a different version by bumping the version in libs.versions.toml in the gradle folder. |
|
The actual fix is in Open Liberty. See this PR. Adding a work around to ci.common for now. Will leave this issue open to remove work around when fix is available in OL. |
|
I've updated the |
|
Sorry for taking a long time to get back. Anyways, this can be closed. We have tried out the latest (3.8.2) release and this issue doesn't occur. |
github-project-automation
bot
moved this from Target fix release
to ✅ Done
in Liberty Tools Release Plan
This issue's an interesting one...and unfortunately, difficult for me to try and get a decent test case for you...
So I'm wondering, were there any changes that could have caused something like this with com.ibm.websphere.ras.DataFormatHelper between version
3.7->3.8of the liberty plugin??I'm not seeing that class get used by my code anywhere. Interestingly, this failure case I've so far only been able to reproduce in our internal library, which utilizes TestKit...But unable to reproduce it outside of that, so far...
But, I can reproduce reliably in our tests and our CI, if I attempt to upgrade to liberty plugin from
3.7 -> 3.8, it fails in this way. Downgrading back to3.7resolves it...(gradle run with -i so it's extra noisey)
This is with
gradle 8.5, I tried with8.4just in case, same result.openliberty-kernel = "23.0.0.11", I bumped this just to see if it would help, no change.The text was updated successfully, but these errors were encountered: