Failure in LibertyPluginSWTBotGradleTest.testDashboardDebugWithCustomConfigAction - widget not found #433
Comments
|
After debugging more, there are a few angles to pursue here:
1.we may simply need to do something like #440 to delete Remote Java App debug configs, not just Liberty Tools debug configs, before a new test. (Note at the moment this PR has some other commits to provoke failures which would need to be removed before merge.) 2.I would like to understand better if the "find" behavior is determined in a straightforward way based on an earlier debug config, or if the "find" behavior is in fact different on the different envs (platform, etc). That is, if there's a leftover Remote Java App 'app' debug/run config, will the LT debug config ALWAYS get created as 'app(1)' and thus NEVER found in the following 3.While the path is well laid-out for us, to a point, by the LTI https://github.com/OpenLiberty/liberty-tools-intellij/ GHA config, there is a problem with LTE. The problem is that the relevant libraries are not already very OSGi-friendly, they do not include bundle manifests. At the moment, the config is done with the help of the org.aeonbits.owner, org.aeonbits.owner-java8 modules. Though Tycho can generate bundle manifests it doesn't generate in such a way that the "split" package can be accessed across both. So the doc here: https://automation-remarks.com/video-recorder-java/ does not work w/o modification. As a POC, I hacked togther both the 'aeonbits' packages into a single bundle and replaced these in my local Maven repo. This got the video generated. (Note, I used the VLC media player, on Android, to view the generated videos). My next effort is to try to write my own extension that provides its own config, so that the aeonbits libs are not needed, from within the LTE test env. (Work in progress: https://github.com/scottkurz/liberty-tools-eclipse/tree/lte-video) |
|
I may have gotten to the same conclusion (aeonbits bundle issue) but from a different angle... There are two main dependencies that are needed from the com.automation-remarks video recorder libraries:
These dependencies can be added to the target platform file like so:
and tycho will generate a manifest for them and bundle them into bundles with the prefix "wrapped" added. e.g. "wrapped.com.automation-remarks.video-recorder-junit5" In trying to recreate Scott's issue with aeobits bundling, I first simplified things and tried to bundle these two dependencies separately. Each had "none" specified in the target platform file for "dependency depth" which means "dont try to bundle any direct or transitive dependencies". I found that the dialog window in Eclipse for the target-platform file was showing an error that video-recorder-core could not be bundles, but this seems benign as the logs for a maven install are showing the bundle being generated. However, the junit5 bundle could only find classes in the core bundle if the core bundle (with "wrapped" prefix) was added as a "Required-Bundle" in our test projects Manifest file. The latest issue is that the core bundle cannot find a class in the aeonbits dependency library:
I then added the com.aeonbits.owner dependency to the target platform, but the bundle does not seem to be generated and no manifest is created as is done for the other dependencies. e.g. for video-recorder-junit5:
I have yet to debug why the aeobits dependency is not being bundled. no obvious errors are shown. This could perhaps be the same issue Scott saw, but given that this is not bundling two dependencies together it seems it may be a different issue. getting past could potentially make this work. Changes are here: https://github.com/awisniew90/liberty-tools-eclipse/tree/video-recorder |
This failure was introduced by an earlier version of #428. It seemed to occur consistently on Linux in particular.
We decided to workaround the failure by configuring the tests to run in alphabetical order. Our guess is that the way to understand this fact is that the error is provoked by runningthe LibertyPluginSWTBotMavenTest tests before the LibertyPluginSWTBotGradleTest tests, and worked around when these are run in the opposite relative order, such that the Gradle tests are run first (it's conceivable there are other complicating factors, including possibly the other test classes).
Opening this issue to follow up on the failure, to understand it better. This will hopefully help us more generally under these SWTBot tests. It's not that running the tests in a predictable alphabetical order is necessarily bad, but we'd like to understand the failure while it's happening consistently, (as it was when merging the PR on top of the HEAD of 2fb4b6b).
The text was updated successfully, but these errors were encountered: