Allow recipe parameters to be specified from the command line

[blipper]

What problem are you trying to solve?

Reduce friction to using OpenRewrite

Describe the solution you'd like

https://docs.openrewrite.org/running-recipes/running-rewrite-on-a-gradle-project-without-modifying-the-build#step-3-optional-create-a-custom-declarative-recipe

Right now the only way to pass parameters to recipes is creating a custom recipe. It would be great to have a command line mechanism similar to

bb rewriteRun  -Drewrite.activeRecipe=foo.Bar -Drewrite.params.foo.Bar.myParam1=paramValue

Have you considered any alternatives or workarounds?

Additional context

Are you interested in contributing this feature to OpenRewrite?

Yes.

[timtebeek]

Thanks for the offer to help @blipper ! For context: we added similar support for the Maven plugin in https://github.com/openrewrite/rewrite-maven-plugin/pull/816, as documented. Ideally these implementations look alike as much as possible.

[wjglerum]

Thanks for the offer to help @blipper ! For context: we added similar support for the Maven plugin in openrewrite/rewrite-maven-plugin#816, as documented. Ideally these implementations look alike as much as possible.

Did one of you manage to pick this up? It would be quite helpful if you could pass in recipe paramaters via Gradle too!

My use case would be to provide a generic recipe to update some dependency through our own custom gradle plugin that includes the open rewrite gradle plugin. We provide the open rewrite capabilities with some generic recipes to the user and allow the user to run the update again with a specific version that they need for some dependency. Or would there be a better way for that @timtebeek with Gradle in this case?

[wjglerum]

My idea would be to do something like this but pass in the newVersion from the commandline with Gradle, see https://docs.openrewrite.org/authoring-recipes/automate-breaking-changes#step-3-write-the-recipe

[timtebeek]

How specific would you want to be with your newVersion argument? Because we tend to use version patterns for unpinned .patch releases, and then named recipes for major and .minor releases; that way you can repeatedly run the same recipe and each time get upgraded to what is at that point the latest patch release, or choose your target major/minor version already. Any reason that wouldn't work in your case?

[wjglerum]

How specific would you want to be with your newVersion argument? Because we tend to use version patterns for unpinned .patch releases, and then named recipes for major and .minor releases; that way you can repeatedly run the same recipe and each time get upgraded to what is at that point the latest patch release, or choose your target major/minor version already. Any reason that wouldn't work in your case?

That looks a bit like Gradle version patterns and ranges and could help indeed, thanks! 👍 I'll have a look at that.

Maybe when I have some time at hand this week I can also look to port the maven implementation of this to the gradle plugin.