The stock releases of OpenJFX have the debug information removed from the builds. More times than not, I find myself in the depths of FX in my debugger, but it’s less useful because the information has been removed.
I have been looking at this page https://wiki.openjdk.org/display/OpenJFX/Building+OpenJFX and have downloaded and successfully built the trunk of OpenJFX on my MacOS machine, using JDK 21. And by “successfully”, I mean the build seems to complete without errors. I did this by simply running “sh gradelw”.
According the gradle.properties.template, the debug build is the default build. I copied the template to gradle.properties, and change the CONF setting to Release, and compared the class files. They are, indeed, smaller, which suggests the debug data is not being generated for release, helping confirm that the default build has the debug information.
On the web page, there is a long list of tasks, including publication tasks. Notably one named ‘publishToMavenLocal’.
When I run ‘sh gradlew tasks –all’, none of the publication tasks show up.
I would like to push this build to maven, so I can change my pom file to use the debug build in order to get better information when debugging my FX projects.
How can I properly publish the build artifacts for OpenJFX to my local Maven repository?
Addenda:
“Variable information not available, source compiled without -g option”. That’s what I get in my IDE when I’m stepping into FX code. So, I can’t view local variables in methods, just the parameters and class variables. This happens with 22.0.2.
The OpenJFX build for “release”, they use -g:source,lines and for “debug”, they use -g:source,lines,vars.
I simply want to deploy the debug artifacts to local .m2 Maven repo.
10
NetBeans supports source level debugging; in this case, the goal is to target the artifacts from building OpenJFX from source. A critical element is ensuring that NetBeans has access to the relevant source artifact. Without this, NetBeans may balk or display a decompiled listing; with it, stepping in and out of code is relatively painless. While this answer isn’t a complete solution, it may offer a way forward.
Maven Project
A maven project, illustrated here, is convenient in that you can right-click on the desired project dependency to download available sources. As yours are local, you may need to resort to the Apache Guide to installing 3rd party JARs.
Alternatively, consider building a Custom JDK+JavaFX Image using the artifacts as built. The resulting run-time image can be added as a distinct NetBeans platform in Tools > Java Platforms.
Ant Library Project
An ant project, illustrated here, offers the advantage of targeting the artifacts in a library, seen here. Simply add the relevant file or folder to the corresponding Classpath, Sources or Javadoc tab.
The typical SDK download includes a file named src.zip; it may appear among your build artifacts. This file is a composite of each module’s Javadoc. Simply adding src.zip to the Sources tab appears to be insufficient. With reference to NetBeans URIs and URLs, you may need to edit the library’s xml directly to access the archive’s internal structure:
<resource>jar:file:/…/lib/javafx-sdk-21.0.4/src.zip!/javafx.base/</resource>
<resource>jar:file:/…/lib/javafx-sdk-21.0.4/src.zip!/javafx.controls/</resource>
…
The file location is platform-dependent; MacOS is shown:
~/Library/Application Support/NetBeans/22/
config/org-netbeans-api-project-libraries/Libraries/JFX.xml
So, my solution to this, in the end, was to just hand craft my own entries in .m2.
I went and grabbed a source release that I think matches the version I’m using (22.0.2 in this case). I then built it using sh gradlew.sh. This creates a full debug build by default. It puts all of the jars in the build/publications directory.
In publications, there’s no source jar, no javadoc jar. Just code jars.
Fine.
So I then donned a caving helmet, turned the light on, and clawed my way down into the .m2/repository/org/openjfx directory.
There are all the different artifacts. Specifically for my use case, I was interested in javafx-base, javafx-graphics, and javafx-controls. Also note there’s a parent javafx artifact as well.
Each of these directories contain, among others, a 22.0.2 directory. Which is the version I was using.
I went into each of those artifact directories, and created a 22x directory as a sibling to 22.0.2. I then copied the contents of the respective 22.0.2 files into the 22x directory. Now, all of these directories contained the code, javadoc, and source jars for each artifact. (Save for the javafx directory which is just a pom file, essentially.)
I then proceeded to copy the appropriate jar files out of the publications directory into their respective places, overwriting the original 22.0.2 jar files.
Next, I renamed all of the 22.0.2 files to 22x files. I then updated all of the poms to reference 22x instead of 22.0.2. Finally, I removed all of the sha1 files.
Once that was all done, I went to my project, updated my pom to 22x, rebuilt it, launched it in debug mode, stepped into JavaFX code, and, et voilà, it worked. There were my local variables.
Then, I turned off my light and took my caving helmet off.
I’d like to argue that I shouldn’t have had to do all this, since the project apparently makes regular releases to maven. I’d prefer to just use their tooling, but this was expeditious.