WINDUP-3128: mta-cli script openrewrite

[m-brophy]

https://issues.redhat.com/browse/WINDUP-3128

this needs this rulesets PR to work: windup/windup-rulesets#570

an openrewrite migration can now be called from the mta-cli script using this format of command:

./mta-cli --openrewrite "-DactiveRecipes=org.jboss.windup.JavaxToJakarta" --input /home/mbrophy/Projects/spring-petclinic-migration --goal dryRun

Argument details:

--openrewrite this is a flag specifying to run an openrewrite migration rather than an MTA analysis. The two cannot be run together simultaneously, it must be one or the other.

"-DactiveRecipes=org.jboss.windup.JavaxToJakarta" This tells openrewrite which recipe to apply to the input project. JavaxtoJakarta is the default shipped recipe but a user can add their own to the shipped rewrite.yml and run that recipe instead if they so choose. The shipped rewrite.yml file is located in the rules/openrewrite/ folder in the unzipped MTA distribution.

--input this is the path to the source project which the openrewrite migration is to be performed upon.

--goal this is the openrewrite maven goal to run. This argument is optional, if not supplied the script will run the dryRungoal which reports on the changes and creates a patch file which can be applied later. To apply the recipe changes immediately without this stage, the run goal can be supplied as this argument instead.

[PhilipCattanach]

@m-brophy My testing went very well I tested he recipes against the spring-petclinic-migration project and all of the import javax.*
packages were replaced, except 2.
The 2 were javax.cache.* packages. But I need to check whether there are jakarta equivalents for those.

/spring-petclinic-migration/src/main/java/org/springframework/samples/petclinic/system/CacheConfig.java:import javax.cache.configuration.Configuration;
/spring-petclinic-migration/src/main/java/org/springframework/samples/petclinic/system/CacheConfig.java:import javax.cache.configuration.MutableConfiguration;

[m-brophy]

@PhilipCattanach Those packages were never officially accepted into java EE, they were part of JSR107
It's unclear to me what we should do about it in terms of migrating these packages.

see here

I suppose we could just leave them as they are, not being part of Java EE

[mrizzi]

@m-brophy one initial "blocker" to be fixed.

[mrizzi]

@m-brophy one initial "blocker" to be fixed.

[PhilipCattanach]

I have repeated my tests after rebuilding to include the latest commit and everything worked perfectly.

[mrizzi]

Tested on Fedora and MacOS and it worked fine 👍
Thanks a lot @m-brophy

[PhilipCattanach]

Successfully tested on Windows 11 and RHEL CSB