gradle-lint-plugin VS rewrite

A little more than two years ago, in October 2019, I began work on my first significant open source project, the Dependency Analysis Gradle Plugin. I had just left a job where I had done relatively little coding, was taking a month off, and wanted to get back into a building mode and learn some new things. I decided to explore the domain of unused-dependency detection. The nearest competitor I was aware of was the Gradle Lint Plugin from the Netflix Nebula collection. However, as that plugin has never supported Android projects, that meant I had an exploitable niche—if only I could exploit it.

Semgrep’s focus is on static analysis/search and is based on rules that developers need to write in a new DSL. Autofix is experimental and is one pattern replaced with another. https://semgrep.dev/docs/experiments/overview/

OpenRewrite originated to do transformations of code, specifically to remove a Netflix proprietary logging library and replace it with in SLF4J. The predecessor of OpenRewrite was Gradle Lint (https://github.com/nebula-plugins/gradle-lint-plugin), commonly used to update Gradle build configuration. OpenRewrite added search after transformation and search can be very flexible (search for all usages of a particular package/any method, not just a specific method invocation). Instead of being DSL based, OpenRewrite provides a set of building blocks called recipes that can be combined together to create more powerful recipes. When building blocks are not enough, you can write a custom recipe in the same language as what you are managing. Java for Java and TypeScript for JavaScript/TypeScript (coming soon).

For example, you can see JUnit 4 to 5 migration recipe contains a set of pre-built and custom recipes.

Also found Gradle Nebula Lint https://github.com/nebula-plugins/gradle-lint-plugin/wiki

If you're into this sort of thing, there's OpenRewrite[1] for the Java ecosystem.

[1] https://docs.openrewrite.org/

> Spring has gotten so bloated.

I'd call Spring feature-rich than bloated. You can always shed weight that you don't want to carry.

> Plus there's multiple ways of doing the same thing. e.g. JPA, spring-data.

That's because there are different ways to solve a problem. Someone may want an ORM-based approach to connect to the database; they can choose spring-data-jpa. Someone may want to use JDBC with a light abstraction on top of it; they can choose spring-data-jdbc. It's all about choices and right tradeoffs and Spring offers plenty of them.

> they don't provide easy upgrade paths between majors versions

That's not my experience. I've been happily upgrading 2.x.x versions and plan to upgrade to 3.2.x when it is ready. But depending on the codebase, I admit it can be painful. Projects like OpenRewrite[1] might help here.

> and they stop updating vulnerabilities on older major versions.

This is not news. They want you to pay for extended support if you need it.

> No docs on migration.

They do maintain migration docs on GitHub wiki which are a lot more detailed than their blog posts on migration. Here's the latest one to upgrade from Spring Boot 2 to 3: https://github.com/spring-projects/spring-boot/wiki/Spring-B...

[1]: https://github.com/openrewrite/rewrite

The issue you may run into when migrating from Spring Boot 2.x to 3.x is the JEE namespace renames. Migrating code from 8 to 17 in my experience hasn't been all that difficult. In most projects, there are no changes to make. However, with the namespace change, you'll probably have to do some planning and testing. If you are migrating a lot of projects, check out Open Rewrite, it may help automate a lot of these upgrades (for both 8 to 17 and Spring Boot versions).

Couldn't OpenRewrite (https://docs.openrewrite.org) do a big part of this manual work?

Openrewrite would probably be a big help, see https://docs.openrewrite.org

In a similar vein there is OpenRewrite which is an open-source project that works in a similar way. It also has a lot of great refactorings already built in, like doing all the grunt work for migrating to JUnit 5, or replacing string concatenation in SLF4J log calls with parameterized formatting.

seems a case for https://docs.openrewrite.org/

https://github.com/openrewrite/rewrite might help