Skip to content

From Quarkus to Spring Boot - #4

Closed
SvenWoltmann wants to merge 15 commits into
with-quarkusfrom
with-spring-boot
Closed

SvenWoltmann wants to merge 15 commits into
with-quarkusfrom
with-spring-boot

Conversation

@SvenWoltmann

Copy link
Copy Markdown
Owner

No description provided.

@SvenWoltmann
SvenWoltmann force-pushed the with-spring-boot branch 3 times, most recently from 84b3f4c to 8813a3f Compare June 14, 2026 14:52
@SvenWoltmann
SvenWoltmann force-pushed the with-quarkus branch 2 times, most recently from 9c06647 to a46a705 Compare June 14, 2026 19:56
@SvenWoltmann
SvenWoltmann force-pushed the with-spring-boot branch 2 times, most recently from 54fecea to f14b899 Compare June 17, 2026 05:55
@SvenWoltmann
SvenWoltmann force-pushed the with-spring-boot branch 2 times, most recently from f9424d3 to e620804 Compare June 23, 2026 10:01
Five analysers ran on this repository: Spotless, SpotBugs, PMD, Checkstyle and
SonarQube Cloud. Most of them said the same things twice.

Checkstyle ran google_checks.xml, which is almost entirely formatting and
naming - and formatting is already decided by Spotless with google-java-format,
so there was nothing left for it to find. PMD's rules are largely a subset of
what SonarQube reports, and so is what SpotBugs finds here.

The cost was not build time. It was five independently versioned tools, each
with its own JDK floor, that all have to be kept moving by hand in a
repository without Dependabot - in four branches that will never be merged.

What remains: Spotless, because formatting is not a matter of judgement and
can be fixed automatically, and SonarQube Cloud, because it is the only one
with a history and a quality gate, and it covers what the others reported.

The three rule and suppression files went too; they existed only to keep the
removed tools quiet. The Sonar coverage and module settings stay.

Verified locally on JDK 25: spotless:check and `verify -Ptest-coverage` pass
in all modules, and no analyser plugin runs any more.
…ect "parent"

The Sonar scanner takes the project name from the Maven project name, which
falls back to the artifactId - and the aggregator's artifactId is "parent".
A <name> on the parent POM is all the display name needs; the artifactId
stays, so the module POMs that reference it are untouched.
1.36.1 formats this code base exactly like 1.35.0: `spotless:apply` rewrites no
file. Raised now, ahead of Dependabot, so that the bump lands together with
its verification instead of auto-merging as a minor update into a red main.

Verified locally on JDK 25 after a `mvn clean`: spotless:check and
`verify -Ptest-coverage` pass.
The badge line and the "Additional Resources" block at the end (the two
cheat sheets, the newsletter, Mastering Data Structures) are now generated
from happycoders-website-astro/data/github-readme by its
sync-github-readmes script, and sit between two marker comments. The block
follows the site's current wording: the newsletter promise is the canonical
one ("Modern Java ... once a month"), the cheat sheets are called free, the
Java versions copy follows the newest release, and the mockup images are the
ones the site uses.

Decided 2026-09-03: the block is always one "Additional Resources" H2 with
the sections as H3, a README has exactly one H1, and it is English except
for the pointers to the German pages and the Mastering Data Structures
section.

Also: only the title is an H1 now - Branches, Architecture Overview, How to
Run and Example Curl Commands were H1s too, their subsections move down one
level accordingly. The "with-spring" branch heading and its paragraph, which
spoke of the with-quarkus branch, now name the with-spring-boot branch.
… import, Launcher

Four catch blocks in the REST adapters bound an exception they never used
(S7467); on Java 25 that is an unnamed variable, `catch (IllegalArgumentException _)`.
The article listing of FindProductsController follows.

GetCartServiceTest imports Mockito's when() statically now, like the other
service tests (S8924).

Launcher.main() keeps its `String[] args`. Since Java 25 (JEP 512) the
launcher also accepts a main method without parameters, so Sonar's S1172 is
technically right - but the conventional signature is what the articles show
and what readers expect from an entry point, so the rule is ignored for the
Launcher in the pom, with the reason next to it.
Since Java 25 (JEP 512) the launcher accepts a main method that is neither
public nor takes the argument array, so the entry point declares only what
it uses: `static void main()` where the arguments are not read, and
`static void main(String[] args)` where they are passed on. The article
listings follow.

The pom no longer needs to ignore Sonar's S1172 for the Launcher.
@SvenWoltmann

Copy link
Copy Markdown
Owner Author

Closing: the with-spring-boot branch is a permanent stage of the article series and is deliberately never merged - the articles link to the individual branches.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants