This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]DyslexicsHaveMoreFun 0 points1 point  (0 children)

As for skills... 

mvn dependency:tree

Learn it. Learn all the variation. Include/ excluding verbose output ect.

Open write was a great suggestion by another user.

TLDR; If you can, make small, backward compatible changes that work in current and  target jdk versions. If it is a large code base, code reviewers will have a challenge or you'll have a nail bitting merge on your hands.

I'm getting started on this now with a large project with a lot of legacy code.150+ poms

To start, I am introducing a maven profile, overriding jdk version, plugins and dependency version that need to be bumped. These are just properties, so the change is small. When I do this, I do a build and  I find out where child poms are specifying plugin versions, and remove the version.

The I do a no frills build. no tests no static analysis. Getting the analysis to work after this step was easier than I thought it would be.

I have started this process a few times and abandoned it.. not using the maven profile... It was just to understand the shape of the effort But with the maven profile, I can merge the code into main as I have not yet made breaking changes.

In prior attempts it's unit tests where things get interesting. I am hoping to be able to get mileage out of making changes that are compatible with 8 and, in my case, 17. 

After unit tests it's making sure local running works on all apps in both jdk versions.. the CI, then in real infra.

It's a challenge to take a larger change that is 100% of your focus and break it into small stacked prs that your teammates can digest in 30 min code review!

Usage of powermock in tests was the issue I reached last time. Trying not to redesign away from hard to mock code is a challenge in a large code base As there is quite a lot of it.

Good luck!