-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add rewrite-templating
annotation processor to also produce OpenRewrite recipes
#925
Add rewrite-templating
annotation processor to also produce OpenRewrite recipes
#925
Conversation
As for the forbidden licenses; these new warnings are logged from [WARNING] There are 7 forbidden licenses used:
Some can likely be merged, although I've only briefly looked into this as I'm not a lawyer to know the exact differences between the number of clauses for instance. Lines 1238 to 1299 in 94023ed
The first three for instance would likely need something like this diff --git a/pom.xml b/pom.xml
index d301c084..39170056 100644
--- a/pom.xml
+++ b/pom.xml
@@ -1253,6 +1253,7 @@
| BSD License 3
| Eclipse Distribution License (New BSD License)
| New BSD License
+ | BSD 3-Clause "New" or "Revised" License (BSD-3-Clause)
</licenseMerge>
<licenseMerge>
<!-- -->
@@ -1296,6 +1297,12 @@
| MIT license
| MIT License
| The MIT License
+ | The MIT License (MIT)
+ </licenseMerge>
+ <licenseMerge>
+ <!-- -->
+ Public Domain
+ | Public Domain, per Creative Commons CC0
</licenseMerge>
</licenseMerges>
<!-- Nearly no projects ship a "missing third party |
The license aliases are all safe; I've added a commit to suppress then. (The formatting, classification and comments may look a bit odd, but this is fully sync'ed from our internal Maven Parent.) |
Added one more commit; build should now pass 👀. The increase in artifact size isn't an issue I think. ✔️ I'll need to play a bit more with the PR before finalizing the review (which may not happen this evening), but let me say: very cool and thanks for pushing this forward! 🚀 |
Looks good. No mutations were possible for these changes. |
Hmm, the SonarCloud analysis fails with:
That's a setup issue on our side; will have to check the docs on that one. (Most PRs we get are from Picnic colleagues, who push a branch to this repo, rather than creating a separate fork.) The JDK 21 build also fails when analyzing the generated sources. If OpenRewrite can be tweaked to generate compliant files: great! Otherwise we'll have to check how to suppress those warnings. (But that may then require a separate compilation phase, which wouldn't be nice. 🤔.) |
Thanks for the quick feedback! Looking at the Java 21 build failures it seems to stumble over new warnings mostly:
What's the magic comment I need to add to the generated template files to make that warning go away? As for the SonarCloud issue: by default forks don't have (and shouldn't have) access to secrets I believe, which might cause your issues here. Not quite sure about what the best way forward is there, since you also don't want untrusted forks from running away with your Sonar and other secrets. Fun times. |
This is one we've also seen on other code; we work around it by making the constructor explicit and adding a comment, like this. Seems a bit artificial, but okay.
Haven't seen that one before, but based on this thread I assume it's about making sure that the Javadoc has an initial summary line. W.r.t. Sonarcloud: there's this feature request. Perhaps it'd be secure if the code on the target branch would be executed. But if we can't find a fix, we can look into making the analysis conditional. (Which would kind of defeat the purpose, but alas.) |
Looks good. No mutations were possible for these changes. |
I added a commit to try and skip the SonarCloud analysis; that worked. Opened a separate PR for that improvement (also to test the "other side" of the equation): #926. |
Looks good. No mutations were possible for these changes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a commit that makes the JDK 11, 17 and 21 builds fully pass, at least locally. Let's see what GHA thinks 👀
...prone-contrib/src/test/java/tech/picnic/errorprone/refasterrules/StringRulesRecipesTest.java
Outdated
Show resolved
Hide resolved
...prone-contrib/src/test/java/tech/picnic/errorprone/refasterrules/StringRulesRecipesTest.java
Outdated
Show resolved
Hide resolved
...prone-contrib/src/test/java/tech/picnic/errorprone/refasterrules/StringRulesRecipesTest.java
Outdated
Show resolved
Hide resolved
...prone-contrib/src/test/java/tech/picnic/errorprone/refasterrules/StringRulesRecipesTest.java
Outdated
Show resolved
Hide resolved
...prone-contrib/src/test/java/tech/picnic/errorprone/refasterrules/StringRulesRecipesTest.java
Show resolved
Hide resolved
Looks good. No mutations were possible for these changes. |
I added another commit to deal with some dual-licensed dependencies; by whitelisting more entries we avoid some redundant build output. Two open points:
Not sure I'll have (much) more time to look into this PR today, so next update may be a while. |
Looks good. No mutations were possible for these changes. |
08246cf
to
93e5cc0
Compare
Looks good. No mutations were possible for these changes. |
Added a commit to see whether indeed only the Windows build tries to run Error Prone against the generated recipes, and the answer turns out to be "yes", because now the other (previously cancelled) builds pass. This'll require more investigation (likely EOD earliest). Will revert the test commit. |
Looks good. No mutations were possible for these changes. |
Seems something got stuck. Since there's now also a conflict with the target branch, I'll retrigger by rebasing. Edit: YAML sync issue, of course 🤦 |
ae8e746
to
f5a73a2
Compare
Looks good. No mutations were possible for these changes. |
1 similar comment
Looks good. No mutations were possible for these changes. |
f5a73a2
to
82f357c
Compare
Looks good. No mutations were possible for these changes. |
1 similar comment
Looks good. No mutations were possible for these changes. |
Right, so for Windows we have
This matches most paths as printed in the logs. However, Error Prone (Javac?) output uses a different path format:
Perhaps we should just match against |
Looks good. No mutations were possible for these changes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Merged master
once more into this branch; the remaining changes belong to this PR proper.
W.r.t. the increased build time: ~5 seconds is due to the new StringRulesRecipesTest
. The remainder was less easy to pinpoint, but at least part of it is of course due to source generation and the subsequent compilation. Anyway, not a big issue.
Suggested commit message:
Derive OpenRewrite recipes from a subset of Refaster rules (#925)
Using OpenRewrite's `rewrite-templating` annotation processor, Refaster rules
are now converted into matching recipes and bundled as part of the
`error-prone-contrib` artifact. Note that not all rules are supported yet.
We should likely also communicate the new functionality in the README and on the website (possibly with a marker on documented Refaster rules for those that support it), but that's for a separate PR. (Especially the website
setup is a bit in limbo right now.)
NB: It may be that #515 is merged before this PR. In that case I can take care of the resultant conflict. |
Done! |
Looks good. No mutations were possible for these changes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Enjoyed reading all the progress in the rewrite-templating
repository. This is really cool stuff and nice to see this milestone 🚀!
Forgot to say; the only thing I wasn't yet able to fix is running the new test in my IntelliJ 🤔. Not sure that works for you guys? |
Did you mark the generated folder as sources in your IDE? |
Looks good. No mutations were possible for these changes. |
I hadn't tried until now (I think), but (IIUC) for me IDEA fails during the build step that precedes the test run. The error I get is:
IDEA did (automatically) mark the directory as a source folder. I tried to add One thing that's interesting, is that OpenRewrite indeed copies over the annotation to the recipe, even though that won't have any functional impact (see e.g. |
Indeed sounds like we ought not to pass that annotation into the recipe; thanks for pointing that out! On the (long) list here to fix, possibly fixed as side effect of |
Top! I think that this isn't a blocker for merging the PR. I synced the branch; will let @rickie merge if he agrees. |
Looks good. No mutations were possible for these changes. |
No blocker, lets merge! Sorry for my late response, I am (still) recovering from being sick.. |
Awesome! Look forward expanding this further in the near future and trying out the next release! |
The IDEA issue described in this comment turns out to be IDEA-342187, unrelated to OpenRewrite; I filed #958. |
Hi all! As discussed both offline and on openrewrite/rewrite-templating#5 here's a PR that adds the
rewrite-templating
annotation processor. This generates OpenRewrite recipes from the same Refaster rules inerror-prone-contrib
, which can then be run through OpenRewrite and Moderne as well using the same jar.Increase in file size
There's an increase in the file size after adding this annotation processor. Nothing shocking in absolute sense, but figured point it out here for review in case anyone is sensitive to that. All dependencies I've added as
<scope>provided</scope>
To do here
Future work in rewrite-templating
rewrite-templating doesn't yet support all features of Refaster used in error-prone-support; here's a quick link to a few open issues. Well possible that we discover more as we go, but figured we can start somewhere and iterate.
return Refaster.anyOf(...)
openrewrite/rewrite-templating#21IndexOutOfBoundsException
onmatcher.parameter(0)
when matchingstr.getBytes(UTF_8).length
openrewrite/rewrite-templating#49Fixes openrewrite/rewrite-templating#5