Nick McKinney

what's puzzling me is that when I run `publishToMavenLocal`, the marker artifact poms *do* get the license. it looks like the `publishPlugins` task (used in the GH Action) does not...

So I'm debugging the Gradle Plugin Publish plugin, and I think this code actually just ignores any customized plugin marker artifact poms. The pink scribbles show how it collects up...

meanwhile, I've opened a PR to at least get license metadata into the plugin itself's pom #308

@timtebeek no preference about releases from me, but I do plan to keep poking at the licenses for the plugin marker artifacts. If you'd rather have that carved away from...

Note: this issue is a bit more visible now that `RemoveTestPrefix` is included in `JUnit5BestPractices`: https://github.com/openrewrite/rewrite-testing-frameworks/commit/cb59832d19f6e44d6a9c5bc5e9f44860b377c3ad

Honestly, I've never used JMockit myself, but that looks like an excellent scope to start with. :) Note that RunWith is JUnit4 syntax, so we may want to be mindful...

Yes, but, I'm afraid that might spam `java.version` properties across multi-module projects -- can we easily check (within a visitor) whether a pom's parent is *also* a project file?

related: https://github.com/openrewrite/rewrite-spring/issues/257#issuecomment-1404160994

I'm not sure that the specific replacements you're doing are generically accurate. This page has a nice summary of source, target, and release: https://www.baeldung.com/java-source-target-options ...and IIRC `java.version` is (by convention)...

@ilozano2 Consolidating `maven.compiler.source` and `maven.compiler.target` down to `maven.compiler.release` at Spring Boot 3.1 feels reasonable; I don't that there's any likely scenario where using the old properties individually is desirable for...