-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dependency Conflict Resolution, Dependency Bump #1360
Dependency Conflict Resolution, Dependency Bump #1360
Conversation
move to all being 5.9.0 to resolve conflicts
…ium.selenium-opera-driver 4.3.0 the operadriver dependency has been superseded by selenium-opera-driver
- selenium-java already declares this
- first instance that doesn't have internal dependency conflicts
- does not have vulnerabilities as reported by the Red Hat Depedency Analytics plugin - also works on asahi
- bug affecting jfx21, jfx22, jfc23 - https://bugs.openjdk.org/browse/JDK-8334593
There's an issue that I can't get quite past on windows in regards to the unit testing. If I run
However, if I run the OpenScreensTest test suite specifically, I don't see this issue. No idea what's going on here. I was able to generate an installer with windows and then install it on windows 11 23H2, so there's that?? edit: I see this behavior with |
notes after investigating other dependencies
|
Heyo, thanks for the work here! I do have a few thoughts. Were you able to get the injector to work properly for commons-csv, jsoup, and commons-lang3? The module injected jars will need to be placed into the module_injected_jars folder, as those are manually added at build time. Without the injected library versions put into that folder, PolyGlot will run at debug time with the newer versions, but be built with the older ones. Conversely, have those three libraries finally been made to be compatible with the module system? If so, that would eliminate the need for the module injection stuff entirely (which would be great, it is a not-great hack, and the reason that those libraries remained un-updated for so long). Regarding the TestPTextInputDialog test... that one has been flakey for a while. I think that there is some odd race condition that comes up when it's tested in automation, but doesn't tend to appear in regular use. If it's causing you too much trouble, feel free to disable the test. I think it's causing more bother than it is doing good. Regarding commons lang and the Java bridge... you're exactly right there. It's unfortunate, but the PDF generation library that I use declined to give me the same educational license for their newer versions which support the module system. The old, clunky version is fundamentally tied to Java 8, which it the only real remaining reason for the bridge's existence (and commons lang). I know that other options exist for PDF generation these days, but it would mean refactoring that portion of code entirely. |
haven't run the module injector yet, will do that next jsoup became a proper module in 1.17.1 if I'm reading this right: jhy/jsoup#2025, so that one is good at least. When I look inside the commons-lang3 jar, I see a module-info.class file in there, but the github repo doesn't have a
sounds good. I'll just ignore that for now. |
Ok! If JSoup has been made into a module, then I think that the jar within module_injected_jars can be deleted entirely. You might need to update src/main/java/module-info.java if the module name that the official release chosen was different than the one I arbitrarily assigned with the injector, but that should be it! |
- commons-lang3 3.14.0 is a multi-release jar - update comment - update build script for jlink to grab location of commons-lang3 - requires testing
found the section in the release notes for |
tested on windows (minus OpenScreensTest) & macos, both tests & installation of packages |
Changes
build_image.py
so thatjlink
is able to find jsoup & commons-lang3's modulesmodule-info.java
& commentsNotes
Tested so far:
Notes:
testPTextInputDialog
. I also see this behavior on the currentmaster
branch, so I don't believe it's a bug that arose as a result of the changes I've made here. Running theOpenScreensTest
suite manually doesn't show this behavior