Specify release flag to build on newer JDKs #2609
Conversation
ctubbsii
commented
Oct 11, 2024
ctubbsii
commented
- Add maven.compiler.release option to force correct cross-compilation to Java 11 when building with a JDK newer than 11, such as JDK 17
- Remove unnecessary java source, target, and encoding config from plugins when those are already specified by properties
- Fix submodule for core/in-memory-accumulo to point to in-memory-accumulo's main branch instead of the one being developed for the accumulo4 branch
- Also fix the license name for Apache-2.0 (the recommended name is the SPDX name) and drop .txt from the license URL
|
It looks like the checks failed because my user doesn't have permission to read from the package repository on GitHub. I'm not sure how to fix that. But, I did test this using JDK 17 with |
ctubbsii
force-pushed
the
support-builds-with-jdk17-and-newer
branch
from
5725f6b
to
9aa7475
Compare
* Add maven.compiler.release option to force correct cross-compilation to Java 11 when building with a JDK newer than 11, such as JDK 17 * Remove unnecessary java source, target, and encoding config from plugins when those are already specified by properties * Fix submodule for core/in-memory-accumulo to point to in-memory-accumulo's main branch instead of the one being developed for the accumulo4 branch * Also fix the license name for Apache-2.0 (the recommended name is the SPDX name) and drop .txt from the license URL
ctubbsii
force-pushed
the
support-builds-with-jdk17-and-newer
branch
from
9aa7475
to
e7a0a59
Compare
|
I force-pushed a few times to try to re-trigger the tests. I couldn't figure out how to get the tests to work in the pull request. I ran the tests manually in my own repo, with it's own local secrets for reading the dependencies from the package repository for the build. Those results are at: https://github.com/ctubbsii/datawave/actions/runs/11301797381 |
* Update spotbugs-maven-plugin * Configure javadoc doclint to 'all,-missing' to prevent noise from missing javadocs
* Fix javadoc issues about the use of uppercase header elements, which breaks the standard conventions of html5 that carried over from XHTML days, which was case-sensitive (and because uppercase looks ugly) * Also fix a few other places where uppercase html5 was used, and remove an out-of-place closing paragraph element (that also used uppercase) * Demote `<h1>` tags to `<h2>` in javadoc comments because javadoc reserves `<h1>` for its own generated headers
* Remove redundant items in POMs * Fix spotbugs issues regarding unnecessary boxing/unboxing primitives
|
I tried to include a few quality issues that were interfering with a clean build with spotbugs, and other things enabled that are activated in the GitHub Actions checks, but I was unable to fix everything, because there are similar quality problems with maven-compiler-plugin, and spotbugs, in some of the microservice dependencies, and it's not clear to me how to get a clean build here without first making commits to those other projects and deploying changes to them (which I'm not prepared to do today... but maybe I can submit some PRs later to fix those... it's kind of hard because there's so many and I don't know where to begin). |
|
Okay, I spent a bit more time with this. With these changes, I was able to get the command This required changing 79 of the 128 pom.xml files I found in this project spanning 27 separate repos that were linked as submodules (which seems like a lot to me for a simple set of changes). Is there an easier way to make changes, or is this complexity inherent to the project's chosen build structure? If I want to make subsequent PRs to fix all the repos pointed to by the submodules, what is the preferred order for submitting those PRs, so that they can be available for the other repos? |
| @@ -358,7 +358,7 @@ final public QueryNode Clause(CharSequence field) throws ParseException { | |||
| if (boost != null) { | |||
| float f = (float) 1.0; | |||
| try { | |||
| f = Float.valueOf(boost.image).floatValue(); | |||
| f = Float.parseFloat(boost.image); | |||
There was a problem hiding this comment.
This spotbugs issue was found with the updated spotbugs plugin. However, it appears that this file is generated code that has been checked in to the repository. Is this file frequently re-generated and clobbered, or is it okay to make these fixes here? Would the code-generation utilities generate better (non-buggy) code if it were updated? Where is that code generator executed?
AFAIK checks do not work with PRs based off of a fork |
