This message was deleted.

We started out with a grails 2 project that has incrementally upgraded since 2011 all the way to grails 5. Grails 3 was by far the most painful upgrade of all of the upgrades. The biggest impact to us over the years are: • Discontinuing Controller tests; we ended up building a mock similar to the earlier grails version as a transition. We still have several controller tests as a result. • The flip-flop on controllers being transactional vs suggesting more business logic in Services. We still have several controllers where we worked around the problem with

@Transactional

• We dropped many plugins that were simple library includes or very basic. • We had to keep session in view enabled given our project size, even though later versions of hibernate really discourage it. • We transitioned more to SpringBoot ways of doing things, i.e. for job scheduling we migrated away from Schwartz, directly to quartz. • Tests changed how they handle transactions, so we added a spock extension to clean up data / make use of newTransaction where we needed to test transaction boundaries.

We upgraded our Grails 2.4.4 application to Grails 4.0.1 in March 2020. @jdaugherty did a good job covering the pain points. I think getting our tests to work was the hardest part for us as well. Like @jdaugherty suggested, we generated a boiler plate Grails 4.0.1 application (tracked in a separate Git repository) and incrementally added domain classes and then services and controllers. I think once the grails 4.0.1 application was ready we made a new branch on our original repository, deleted the 2.4.4 application, and copied and pasted over all the code from the 4.0.1 application.

From a previous post I did: | Here are my postmortems of two of the upgrades I've done: | https://dev.to/virtualdogbert/grails-2-5-5-to-grails-3-3-10-postmortem-520a | https://dev.to/virtualdogbert/grails-3-3-10-to-4-0-2-postmortem-5kj | |Gives you an idea of what's involved and as I've said before the pain in upgrading is the number of bad practices you have * the size of your | project. Upgrading from 2 to 3 forces you to abandon a lot of bad practices, so once you get to upgrading to 4 it's easier just by the nature | of getting rid of those bad practices. In my opinion, I would go straight to 5.3.3, getting past 3.x is the biggest leap, but everything below 5.x is EOL. I view plugins that aren't maintained by the Grails teams as just good starting points for integrations and you may have to take them over an maintain them yourself one day. A lot of build plugins were shifted to Gradle plugins. For testing controllers, I've gone to API integration tests using Rest Assured combined with Spring RestDocs. Example app: https://github.com/groovyduke/rest-docs/tree/g5 What I've usually done to upgrade is similar to the above, but for the big upgrade, I would create an example app of my target version and port over the code, using finds and replaces to fix as much as I could. In my current job, they had a conversion script using sed and awk. although that was about 1 million lines of Groovy Grails code spread across several apps and took years to upgrade successfully from 2.5 to 4 and then I did the upgrade to 5 in a couple months, most of which was trying to get QA to test it. Also, look up the Upgrade guides and change the version in the URL to get the older versions back to 2.x

Thank you for your suggestions! We actually are lucky to have not used many plugins, my main concern was the "spring-security-core" plugin which is not available for version 5+ it's still in the documentation: https://grails.github.io/grails-spring-security-core/5.0.x/index.html. We started in the beginning of 2022 and I thought maybe when we migrate to Grails 4 first after migration the plugin could be available for Grails 5. Then the migration was paused because of more pressing issues but now after more migration pauses management is ready to to swallow the pill and let us finish it (hopefully).

Spring security core is "avaiable" and has been for all version of grails: https://github.com/grails/grails-spring-security-core https://github.com/grails/grails-spring-security-core/tags Sometimes that documentation can get a little out of date. I'll ask about that. In my experience, the initial upgrade doesn't actually take that long, depending on how big the code base is and how many bad practices you have to fix, that are no longer supported. What takes time is getting QA to do a full regression to find any issues your tests don't cover, and that you don't find testing yourself, and doing cycles of that till you have something you can release. Another problem that comes up is that if while doing the upgrade and testing cycles, and your team is expected to continue to add features and code. This will lead to cycles of it working on the old version, but now to have to fix it because it breaks on the new version and possible merge conflicts. I've found that using integration test with RestAssured is fairly simple once you get set up. The setup takes a little bit. You don't have to do the Spring RestDocs, but it is a good way to document your API. The benefit of doing integration tests that way is you are testing actual code, the way it would be tested if you just spun up your server and interacted with it. One of the challenges with that is you would need a database/datastore pre-setup, and using test containers is a good way to do that. Personally I never really did or pushed for controller unit tests because controllers should be very simple, and only deal with taking in parameters(preferably through command objects), calling services, rendering views(GSP/JSON), and doing redirects. All other code/business logic should be in services. Services are where I would focus my unit testing.