Move documentation examples off source-available recipes

[MBoegers]

Six documentation pages taught recipes that ship under the Moderne Source Available License. Five now use Apache-licensed recipes; the sixth carries a notice, because its examples are baked into screenshots.

Onboarding guides

• running-recipes/getting-started.md Step 6 used org.openrewrite.java.spring.boot2.SpringBoot2JUnit4to5Migration from rewrite-spring
• running-recipes/running-rewrite-on-a-maven-project-without-modifying-the-build.md used org.openrewrite.java.migrate.jakarta.JavaxMigrationToJakarta from rewrite-migrate-java

Both now use org.openrewrite.java.jackson.UpgradeJackson_2_3 from org.openrewrite.recipe:rewrite-jackson. It fits the same slot — a well-known library migration living in an external artifact you have to add as a dependency, with no options to configure — and it is Apache-licensed through its entire recipe list, not just at the top. That last part matters: rewrite-micronaut and rewrite-quarkus are Apache too, but the Micronaut composites reach rewrite-migrate-java one hop down, so picking on the surface license alone would have moved the problem rather than fixed it.

Reusing the same recipe on both pages is deliberate. A reader arriving at the Maven page from the quickstart already knows what the recipe does, so the page teaches only the thing that differs: invoking an external-module recipe from the command line instead of the build file.

Two things came along with the swap. The outcome prose on both pages described changes the old recipes made ("your project should be upgraded to Spring Boot 2 and the JUnit 4 dependency removed") and would have been wrong left as-is. And the Step 6 preamble claimed the Mockito, JUnit and AssertJ recipes live in rewrite-spring — they live in rewrite-testing-frameworks, which was already wrong before this change.

Styles and reference pages

• concepts-and-explanations/styles.md and reference/gradle-plugin-configuration.md → the same Jackson migration
• reference/yaml-format-reference.md → org.openrewrite.java.RemoveUnusedImports in the precondition example, which also renames the example recipe and updates the two prose references to it

styles.md needed more than a substitution. Its "Using styles" section had three tabs showing three different examples: the Gradle tab activated someRecipe, the Maven tab had <!-- Recipes here -->, and neither put a recipe on the classpath, so neither snippet would run. The command-line tab referenced org.some.style.name, a style defined nowhere on the page. All three now activate the same recipe from the same artifact with the same style — com.yourorg.YesTabsNoStarImports, the one the page defines earlier — so the page can be read top to bottom on one example.

A migration was chosen over AutoFormat deliberately. Styles govern how recipes format the code they write; demonstrating that with a formatter shows only reformatting, and argues OpenRewrite down to a formatter. AutoFormat still appears further down in "Reformatting your code", where it belongs.

The page that cannot move

running-recipes/customize-recipe.md walks through the Moderne recipe builder, and six of its ten screenshots show CommonStaticAnalysis, MultipleVariableDeclarations and the Spring Boot 3.3 tree by name. Swapping the text without redoing the captures would leave the walkthrough contradicting its own images, so the page gets an <MsalNotice> instead. Tracked on our internal tracker as moderneinc/customer-requests#3095.

That page draws on three source-available modules and MsalNotice took one, so it now accepts an array as well. The single-string form is untouched, and the thirteen pages already using it render exactly as before.

What this does not change

None of this removes the Code Genome Project credential requirement. Every page here already states that all OpenRewrite releases, the Maven and Gradle plugins included, are published there and need authentication. What changes is that the recipes being taught are Apache-licensed, so five of the six pages need no notice at all.

yarn build passes with no warnings and no broken links.

[mike-solomon]

Approving - but there is one thing we need to fix prior to merging this in.

[mike-solomon]

The spring petclinic project that we are using as an example here does not have Jackson in it. If someone ran the stuff being suggested in this guide, they won't actually see any of the changes we're claiming they will see.

We need to do one of these:

1. Pick a new recipe that makes sense for the project OR
2. Point to a different sample repository other than spring petclinic OR
3. Update the documentation to be clearer that they need to run this against their own repo that has Jackson or whatnot

I feel like it would be best to make it so someone could go through this guide and see the changes in a repo we've given them. I can't find any recipe that would work well here, though. Maybe that's something you can help with?

[MBoegers]

Good catch! How do you feel about adding a Jackson using class to the openrewrite/spring-petclinic-migration used in this guide?
We own this project anyway.

[mike-solomon]

Good idea! Fine by me.

[MBoegers]

I'll go head and add one

[MBoegers]

Confirmed — nothing in the sample used Jackson, so the recipe ran and changed nothing.

Added it to the sample instead: openrewrite/spring-petclinic-migration#8. With that in place, Step 6 rewrites eleven things across VetSerializer.java and pom.xml.