How long to keep OpenRewrite in a project

[ksader-gumgum]

I have a fairly defined set of work to port forward many libraries in a legacy project. How long should I expect to keep this plug-in as a project level item? Once my porting is 'done' should the expected lifecycle be to remove this plug-in?

My idea of the lifecycle:

Legacy Code -> Rewrite a dependency -> test functionality -> repeat until all legacy libs are upgraded -> Remove plugin?

Thanks,

[tkvangorder]

It may not be entirely obvious at first but there are several use cases for keeping the plugin inside your project after you have done your migrations:

• Static analysis remediation. Think something similar to SonarQube except this tool will also fix many of those issues rather than just reporting on them.
• Source Code Formatting (You can use the plugin to format the code to your standards and you can also fail a build if there are deviations from that standard. Open rewrite's formatting configuration follows closely with the options you see in Intellij.)
• Semantic transformation (If you have ever found yourself writing a regular expression to find and replace source code for anything, think of OpenRewrite as a better tool for this kind of job)

[jbessels]

Been using OpenRewrite (OR) for 7-8 weeks or so. Getting the code clean is the most work. After that itn my experience that the code stays clean. We have a 3 week sprint and I run OpenRewrite at the end of the sprint for those repo's which have changes in it. NOT every build cause it takes to long (building the LST with OR) and be to costly as for BitBucket we pay for every minute a build runs. Re cleaned it for 2 sprints now. Only minor changes found each time. Devs (like me) have this tendency to re use code or get inspiration from existing code and now they do that using cleaned code. There are also recipes for removing unused imports. Make sure to really search for the hidden gems in OpenRewrite's long list of recipes ;-)

Same goes for framework/plugin updates. If NOT done for a long(er) time you will find out some 'surprises'. If after that you do it on regular bases e.g. end of every sprint or revery 2 sprints most of the time its very smooth sailing - and far less CVE security issues. As you are using OpenRewrite (hence only usable for one repo at a time) the Maven versions plugin (Gradle has something similar) might be even more suited for upgrading. As no LST needs to build its much much faster as it just operates on the pom files. It updates all pom files in a repo. It also has the advantage that you can have a maven-version-rules.xml file where you have control of what to exlude and fix frameworks to a certain version etc. I can be mistaken but I don't think OpenRewrite has that (yet). I really do like OpenRewrite but sometimes for certain things other plugins are better/faster and worth pointing out.