When viewed in dark mode, some images are dreadful in README.md.

After upgrading SpotBugs:

[INFO] --- spotbugs-maven-plugin:4.7.0.0:check (default) @ modern-java-practices ---
[INFO] BugInstance size is 4
[INFO] Error size is 0
[INFO] Total bugs: 4
[ERROR] Medium: Method lists Exception in its throws clause. [demo.ApplicationIT] At ApplicationIT.java:[line 19] THROWS_METHOD_THROWS_CLAUSE_BASIC_EXCEPTION
[ERROR] Medium: Method lists Exception in its throws clause. [demo.ApplicationIT] At ApplicationIT.java:[lines 19-22] THROWS_METHOD_THROWS_CLAUSE_BASIC_EXCEPTION
[ERROR] Medium: Method lists Throwable in its throws clause. [demo.TheFooTest] At TheFooTest.java:[line 33] THROWS_METHOD_THROWS_CLAUSE_THROWABLE
[ERROR] Medium: Method lists Throwable in its throws clause. [demo.TheFooTest] At TheFooTest.java:[line 55] THROWS_METHOD_THROWS_CLAUSE_THROWABLE

Batect has been archived by it's author after long effort. Credit to @charleskorn and his incredible work.

This project needs to pivot from Batect to another "build as container" system. The sensible option seems to be Earthly.

Hi @binkley, just came across this repository, looks great!

Having read the README, I'm finding myself querying a bullet point that says, "Java 15 is the current LTS ("long-term support") version". I was under the impression that Java 11 was the latest LTS version, and that the next one will be Java 17. Have I misunderstood something here?

Organize the Issues and build a backlog with priorities.

Unclear why, but the Gradle Modernizer plugin began failing dependency checks last week, after having passed previously, although the version of the plugin has not changed for ages.

See: https://cve.circl.lu/cve/CVE-2021-26291

(Modernizer's Gradle plugin depends on an older version of Maven infrastructure.)

More than just mention Earthly in passing in README.md, provide a working Earthfile, and update GitHub actions accordingly.

refs:

• https://github.com/earthly/earthly/tree/main/examples/java
• https://github.com/earthly/actions-setup

It turns out Gradle, because of it's split between command-line client and background daemon, uses separate settings for the JVM (ie, the --add-opens java.base/java.lang=ALL-UNNAMED flag for plugins based on Ant -- which default Gradle has several of) between those two, and using --no-daemon falls into an not-well-documented mix of client/daemon settings.

Solution is to use JVM_FLAGS in the Batect/Docker build.

(Interestingly, local Gradle build does not show this behavior.)

When loading https://github.com/binkley/modern-java-practices/wiki/Commits in a browser, the XKCD image of bad commit messages does not appear but shows as a broken icon. The link through to the source of the comic works.

Goals:

• Provide example generation of Docker images in Gradle & Maven
• Discuss diffs between JDK 11 and JDK 17 for choice of parent image

https://www.testcontainers.org/ is recommended for system/integration testing needing to bring up the full application, connecting to a disposable test database, etc.

These kinds of tests should be rare for the main code base which relies on unit tests or "slice" tests ala Spring Boot's approach, and so forth, but are important for higher levels of the test pyramid like user journey tests and such.

Previous README.md was everything together in sections of a single file. That remains helpful.

Either:

1. Provide a link to a "everything" page for long reading & printing.
2. Clarify at top, and put the pages into the README.md — how to keep updated?

Key -- how to automate?

Publish to gh-pages branch for the project.

A challenge is duplicated documentation between the wiki and the README.md.

Batect repulls the AdoptOpenJDK11 image each CI run

The current Maven PMD plugin relies on classes from 6.x PMD. Gradle's PMD plugin does not have this concern.

PMD provides a "pmd-compat6" jar usable by the plugin to patch the differences.
This needs removing once the PMD plugin catches up.

See pom.xml and:

<dependency>
    <groupId>net.sourceforge.pmd</groupId>
    <artifactId>pmd-compat6</artifactId>
    <version>${pmd.version}</version>
</dependency>

Without this, the plugin falls over. Tempting, but ./mvnw dependency:resolve-plugins does not reveal the problem.

Picture HTML tag and GitHub footnote markdown

This is an image that depends on time of day¹:

The kbd tag

What does Enter (aka ⎆) or Return (aka ⏎) look like?

Dependabot offers PRs for Maven, but not for Gradle. Find out why this is, and address.

DependencyCheck 8.1.2 has begun failing the Gradle build -- but not the Maven build -- for an outdated Guava version against a 2020 CVE.

Recheck suppressing this when DependencyCheck next updates.

See google/guava#4011.

How to flag TODOs in Gradle and Maven?

BCEL from Apache Commons has a security vulnerability, CVE-2022-42920.
Spotbugs relies on this library, but presently uses a pre-fixed version of BCEL.

Cleaning this up in the build configuration is messy: Best addressed when Spotbugs releases an update that includes a newer BCEL version.

When run batect gradle build, if it has errors the report link is not right.

Checkstyle rule violations were found. See the report at: file:///code/build/reports/checkstyle/test.html

This is part of the epic #586.

I would like to show a badge on the project for build stability: what has been the recent pass/fail rate, and bucket those into good descriptive words.

This will help teams visually spot when a project is going through rough times (could be the code, could be the environment).
Ideal would be to have knobs to tweak to configure. Example:

• Green if last 5 builds were green
• Amber if last 5 builds were a mix of red & green
• Red if last 5 builds were red

An example with the right approach is https://github.com/dwyl/repo-badges but it is unclear how to use in this project.
See dwyl/repo-badges#53.

From ./mvnw site:

Warning:  An issue has occurred with pitest-maven:1.7.4:report report, skipping LinkageError Receiver class org.pitest.maven.report.PitReportMojo does not define or inherit an implementation of the resolved method 'abstract void generate(org.apache.maven.doxia.sink.Sink, java.util.Locale)' of interface org.apache.maven.reporting.MavenReport., please report an issue to Maven dev team.
java.lang.AbstractMethodError: Receiver class org.pitest.maven.report.PitReportMojo does not define or inherit an implementation of the resolved method 'abstract void generate(org.apache.maven.doxia.sink.Sink, java.util.Locale)' of interface org.apache.maven.reporting.MavenReport.

Expected behavior: this is all cached, and not redownloaded on each CI run.

NB -- ignore the adoptopenjdk image download: To be addressed separately from this issue.

Running build-maven...
Pulling adoptopenjdk:11-jdk-hotspot...
Pulled adoptopenjdk:11-jdk-hotspot.
Running ./mvnw --strict-checksums clean verify in build-env...
[INFO] Scanning for projects...
[INFO] 
[INFO] --------------< hm.binkley.md:modern-java-practice-maven >--------------
[INFO] Building Modern JAva/JVM build practices 0-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.5/maven-clean-plugin-2.5.pom
Progress (1): 2.7/3.9 kB
Progress (1): 3.9 kB    
                    
Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.5/maven-clean-plugin-2.5.pom (3.9 kB at 33 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.5/maven-clean-plugin-2.5.jar
Progress (1): 2.7/25 kB
Progress (1): 5.5/25 kB
Progress (1): 8.2/25 kB
Progress (1): 11/25 kB 
Progress (1): 14/25 kB
Progress (1): 16/25 kB
Progress (1): 19/25 kB
Progress (1): 22/25 kB
Progress (1): 25 kB   
                   
Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.5/maven-clean-plugin-2.5.jar (25 kB at 616 kB/s)

Note that "test-sets" plugin used for integration tests relies on removed features available in Gradle 7 and prior:

unbroken-dome/gradle-testsets-plugin#131 (comment)

Part of this issue is to switch to the "jvm-test-suite" plugin:
https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html
It's not as elegant as "test-sets", so research if there is a 3rd-party plugin that wraps up the work for the new API.

CPD works for Maven

Provide Gradle and Maven configuration in Batect, and README update for an example of debugging with an IDE your program running in a container.

Many resources to explain this. Document in README.md

• Gradle -- https://blog.gradle.org/log4j-vulnerability
• Maven -- use dependency management to force-upgrade to versions of log4j not affected

In the docs, note that DependencyCheck catches these
Check that transitive dependencies fail the build as well

NOTE -- this demo project does not use Log4j

https://dagger.io/
This was mentioned to me by @charleskorn.
It is one of other alternatives for a containerized build.

Background
Originally, the builds were containerized in Batect. The maintainer (Charles Korn) has move on from this project, and the best option is Earthly. Research other options, and provide alternative config/scripts for keeping your build identical in CI and local.

Dagger is in the style of Gradle: Programming your build.
Consider wiki discussion on declarative vs programmed builds.

The front page of Dagger offers:

Transform your Messy CI Scripts into Clean Code
Powerful, programmable open source CI/CD engine that runs your pipelines in containers — pre-push on your local machine and/or post-push in CI

See andygoossens/gradle-modernizer-plugin#1

The maven-surefire-report-plugin dependency is declared twice inside the pom.

Show variants in the runscripts depending on platform/libraries.

For example, Spring Boot will rewrite the basenamed jar to just <name>-<version>.jar, but vanilla Maven uses <name>-<version>-jar-with-dependencies.jar.

Does anyone use Maven "site"? Perhaps drop Maven site.

Running ./mvnw site is very noisy. It isn't clear what is working/broken.

Some Maven plugins may only write their results for the "site" target. Address this.
For example, update the target location of the Maven profiling plugin:

• Maven profiler writes into $PROJECT/.profiler/ by default; write into $PROJECT/target/ instead of $PROJECT/target/site/ (see https://github.com/binkley/modern-java-practices/wiki/Performance-problems)

The HTML report for Spotbugs is generated for Gradle, but not for Maven.

See https://earthly.dev/

The Groovy code in build.gradle for dependencyUpdates task is bad. It's a copy from a Kotlin project, and has incomplete translation to Groovy.

Current tooling has not caught up with Java record classes

The README build badge has not loaded for some time.
Investigate and fix.

The advice here is strongly towards containers (like Earthly), but it is good to show working examples of relying on direct GitHub containers in the CI pipeline when a project does not have a local build that matches CI.

This is both reading & code samples.

Result of this card should be:

• GitHub workflow for Gradle directly without using Earthly
• GitHub workflow for Maven directly without using Earthly

Current README.md is 1873 lines and 10,784 words in length. This is excessive.

Consider strategies to break this up into meaningful, digestible chapters in separate files, possibly using the GH wiki feature.

Google's Error Prone for Maven gives good instructions that work.
For Gradle, https://github.com/tbroyer/gradle-errorprone-plugin does not seem to work out of the box.

TestSets plugin fails with Gradle 7.0

Thanks for pulling this together @binkley, it's a great resource.

I'm interested in understanding more about this comment in the readme:

Do not run Batect in your CI pipeline directly: use GitHub Actions (or GitLab equivalent). Batect is for your local build. (This is the classic "Docker in Docker" issue, and there are ways address this , if it is important for your team.)

I haven't seen any issues with running Batect inside GitHub Actions - have you encountered any issues? From what I understand, GitHub Actions spins up an ephemeral virtual machine, not a container, so there shouldn't be any issues with Docker in Docker.

I strongly encourage teams to use Batect both locally and on CI - this ensures that the environment remains consistent in both places, making it easier to reproduce issues (or catch problems before they even become issues).

Following on from my last issue #1, I was also under the impression that AdoptOpenJDK 8 was still being supported, which the following link on the website seems to confirm: https://adoptopenjdk.net/support.html. However I'm not sure if this applies to all distributions of OpenJDK 8. Any thoughts on whether this info should be included on the README or not?

Issue #266 points out that there is no linter for the build itself.

Research what approaches/solutions are available.

CPD (part of PMD) runs for Maven (including report), but not for Gradle.
This seems a request on the Gradle plugin project, but unclear how to progress.

Hello, I was skimming over the README, and realized there's a dead/incorrect link.

The following link: [Intelligent laziness is a virtue](http://threevirtues.com/). redirects me to a place that sells bath salts?

Link is here in the code (couldn't get the permalink atm):
https://github.com/binkley/modern-java-practices/blame/master/README.md#L299

See broader card, #466.

Proposal

1. Move this card to done with "wontfix" label. The "Buildless" tool suggested in this card is commercial.
2. Keep #466 (GitHub caching) as an active card -- it is orthogonal to this card.
3. Add a card for Earthly caching (build container), which would interact with point 2.

Hey there @binkley,

We make a build cache tool called Buildless, with support especially for Gradle and Maven.

I was wondering if you'd be open to me filing a PR to add it to this sample.

Buildless is usable both as a cloud and entirely for free, through a local agent which accelerates Gradle's cache traffic. It does so by upgrading from HTTP/1.1 to HTTP/3.

Point is, it's a great tool, and the agent can be used for free and without an account. Is this the kind of thing that would be good to add?

Also, thanks for making this 😄 it's a pain to get started on a new Gradle project and this looks great

It's been 4 months since JDK 21 release, it would be good to update project (and README) to use it.

Also I'm not sure that the wordings in README:

Java 17 is the most current LTS ("long-term support") version

Should be more like:

Java 21 is the most current version that has LTS builds available

Because Java per se doesn't have LTS, only the distribuitions/builds of Java have LTS.

In this project, you'll see the choice of Java 17 as this is the version to recommend in production.

Why is 18 or 19 a bad choice? There is nothing inherently bad in those versions, they are not less tested or "beta". The only difference is that none of the vendors publishes security patches to them after the new version is released -> forcing to do the upgrades every 6 months, which is a good practice.

I would drop the "recommend in production" unless a good explanation is given.

OWASP complains about commons-io 2.6. 2.8.0 is current version

Work out how to update a plugin dependency without making it a runtime dependency.