Integration of OpenRewrite

[hohwille]

As a IDEasy user, I want to be able to run OpenRewrite on my project so that I can refactor and modernize my code.
I would like that IDEasy offers shortcuts and easier syntax for common use-cases (recipes) since usage of OpenRewrite is rather complex.

Example/Idea:
ide rewrite assertj would trigger all recipes that migrate to AssertJ (e.g. hamcrest to AssertJ and JUnit to AssertJ)
Still I could run a full recipe like:
ide rewrite org.openrewrite.java.testing.hamcrest.HamcrestMatcherToAssertJ for the single recipe as a shortcut for

mvn -U org.openrewrite.maven:rewrite-maven-plugin:run -Drewrite.recipeArtifactCoordinates=org.openrewrite.recipe:rewrite-testing-frameworks:RELEASE -Drewrite.activeRecipes=org.openrewrite.java.testing.hamcrest.HamcrestMatcherToAssertJ -Drewrite.exportDatatables=true

For recipes we newer knew about and do not have supported in our code, we still need a generic usage:

ide rewrite --artifact=org.openrewrite.recipe:rewrite-testing-frameworks:RELEASE org.openrewrite.java.testing.hamcrest.HamcrestMatcherToAssertJ

However, the cool thing would be to have support for known recipes in our code so we can ommit --artifact=... option and make things much easier.

Then we define short names for recipes or groups of recipes like suggested with ide rewrite assertj that would technically run

mvn -U org.openrewrite.maven:rewrite-maven-plugin:run -Drewrite.recipeArtifactCoordinates=org.openrewrite.recipe:rewrite-testing-frameworks:2.14.1 -Drewrite.activeRecipes=org.openrewrite.java.testing.assertj.JUnitToAssertj

AND

mvn -U org.openrewrite.maven:rewrite-maven-plugin:run -Drewrite.recipeArtifactCoordinates=org.openrewrite.recipe:rewrite-testing-frameworks:RELEASE -Drewrite.activeRecipes=org.openrewrite.java.testing.hamcrest.HamcrestMatcherToAssertJ

Theoretically if REWRITE_VERSION is set to an explicit version, we could omit -U and specify the explicit version of open-rewrite
org.openrewrite.maven:rewrite-maven-plugin:«version»:run

[yurii-yu]

Thank you @hohwille . Below I listed some topics to discuss:

1. Which recipes do we need to offer? Do we only consider recipes for Java right now? or do we need to include recipes for other programming languages such as Python or C#.
2. What build tools do we need to support? Only maven, or should we also support gradle?
3. Personally I have some concerns about the names of our own command (I call it wrapped recipe). I would use two separate commands for the example you mentioned above, because each "refactoring" is specifically FROM here TO there . Simply specifying the destination will cause confusion. Think about the case if the use just want to refactor JUnit to AssertJ, while keeping hamcrest unchanged. What should they do? Instead, it is much more clear and easy to use two separate commands.

So here are my suggestions:

1. every wrapped recipe is specific, including 3 parameters: FROM, TO, Version(optional). If no Version is present, then the latest version will be used.
2. we include all available wrapped recipe in a configuration file under the resources folder. So no code will be changed if we want to include more recipes in the future. We can simply use the NLSBundle class to handle this configuration file.
3. to avoid invasion of existing project, we only call openrewrite in the command-line form, which means files other than source code, for example, pom.xml, won't be touched.

[yurii-yu]

after the conversation on Friday, Feb 21st, we reached these agreements:

1. at the beginning we only offer solution for Java
2. only Maven should be considered at the beginning, because it is popular and offers the least invasive interface
3. to avoid confusion, we should name our wrapped recipe clearly, like Junit4ToJunit5, which clearly suggests what the recipe does, and the user will not be confused by guessing he/she can replace Junit4 to Junit3 (just for an example).
4. we can use a configuration file for the mapping from our wrapped recipes(defined by us ) to raw recipes(defined by OpenRewrite).
5. the IDEasy commands for OpenRewrite will only call the OpenRewrite commands in the command-line form. We won't change pom.xml

[yurii-yu]

Generally speaking, these parts need to be done:

1. the "raw" part, calling OpenRewrite command in IDEasy
2. the AutoComplete part, which suggests all available parameters for IDEasy (possibly with prefix-filter)
3. the HELP information, which shows the usage of this rewrite command

[yurii-yu]

Generally speaking, what we need to do are:

1. make sure MAVEN is installed, as the premise
2. take the input from the end-user, map it to the RAW maven command with OpenRewrite, and forward it to the MvnBasedLocalToolCommandlet. For example, ide refactor remove_unused_imports will be mapped to mvn -U org.openrewrite.maven:rewrite-maven-plugin:run -Drewrite.activeRecipes=org.openrewrite.java.RemoveUnusedImports -Drewrite.exportDatatables=true, then the command will be executed with existing code. This is obviously an ideal option.

The second step involves a pre-processor of the interpretation of the input. Since there might be more such pre-processors in the future, it might be helpful to add a feature to integrate some Auto-Discovery-and-Registration features like the Spring framework, by which such processors will be loaded automatically.
If so, there are 3 options:

1. introducing some 3rd-party library such as the Reflections;
2. use the ServiceLoader, and maintain a file listing all classes, under `META-INF/services/'
3. scan CLASSPATH manually