Juicebox
Juicebox copied to clipboard
aidenlab
Build Juicebox with a GithubAction to standardize builds
Initially, I just wanted to start using Juicebox to curate my first primary assembly created with the 3dDNA pipeline. However, with juicebox_2.16.00.jar, the latest build that I could download from the respective Github Release page, I failed to do so.
On my machine (An Apple M1 MacBook with macOS Monterey 12.5.1 and openjdk 17.0.2 2022-01-18 LTS OpenJDK Runtime Environment Zulu17.32+13-CA), I completely lack the right-click menu. Nothing happens when one does a right-click. On the terminal, this error message is shown every time a right-click is recorded:
Exception in thread "AWT-EventQueue-0" java.lang.IllegalAccessError: superclass access check failed: class com.jidesoft.plaf.aqua.AquaJidePopupMenuUI (in unnamed module @0x59a635aa) cannot access class com.apple.laf.AquaPopupMenuUI (in module java.desktop) because module java.desktop does not export com.apple.laf to unnamed module @0x59a635aa
A colleague suggested compiling the software myself to fix this error, however I got a bunch of problems while compiling and getting the dependencies straight. Therefore, I presumed that it might be an issue with the M1 Macs and that building it first on a Github hosted Runner for the sake of standardization might be the better approach.
Hence, I propose in this draft PR a Github Action Continuous Integration pipeline, that is intended to provide a more standardized way of building Juicebox in the future, such that with every new release, the software will be automatically compiled and added to the respective Releases in a reproducible way. Dependencies are resolved with Ivy and for signing the resulting jars, the repository's secrets can be used.
I think, I have already gotten quite far, but like when attempting to compile locally, the runs now fail at the stage of compilation. Since I am not a Java developer and have never written a single line of Java code, I unfortunately can't troubleshoot those error messages. Maybe someone from your lab is interested to take over at this point?
@sa501428 and others: Thanks for taking a look at it! Unfortunately, it escaped me that you were already working on refactoring the builds. In that case, you could still use a slightly modified version of the Github Action, but I would not recommend adding Ivy then.
I just resorted to it, because it was designed to be used together with Ant and I wanted to be conservative with regard to the existing codebase. However, its documentation is horrible and much better tools like Gradle exist - in particular when Kotlin is used. Directly switching to that would be the much smarter choice, if you are anyway turning everything in the codebase upside down.
Should I close the PR then?