Handling Vastly Outdated Plugins: A Modernization Approach

[gounthar]

Discussed in #119

^{Originally posted by gounthar July 24, 2024}

Recent Experience

This week, I attempted to modernize an old plugin still using Java 6. Our current set of recipes failed, necessitating the use of existing OpenRewrite recipes for Java modernization before applying our custom recipes.

Challenges Encountered

1. Compilation Verification: Checking if the plugin still compiled after each set of applied recipes was a major challenge.
2. JDK Compatibility: Unable to verify with JDK 11 or 17, I had to revert to JDK 8. For plugins last compiled with JDK 6, verification with JDK 6 might be necessary.

Proposed Approach

Before applying any recipe, we should:

1. Attempt to compile the plugin (without tests) using the specified Java version.
2. Apply the recipe only if the initial compilation succeeds.

Considerations

• Recipe Metadata: We may lack information about which JDK to use with specific recipes.
• JDK Version Recipes: For JDK version-specific recipes, we should run them with the target JDK.

Tools and Techniques

• Used sdkman to switch between Java versions.
• Successfully upgraded a plugin to JDK 17. 🥳

Potential Solutions

1. Script Generation: Create scripts to switch JDK versions based on recipes using Temurin JDK versions.
2. Java-centric Approach: Explore more Java-native solutions instead of using exec().
3. Jenkins Controller Delegation: Use API calls to delegate compilation checks to another Jenkins controller.
4. GitHub Actions: Utilize GitHub Actions on our forked plugin repositories for compilation checks.

Questions for Consideration

1. Can we integrate JDK switching directly into our product?
2. Is there a more Java-centric approach to handle compilation checks?
3. Should we explore delegating checks to external systems (Jenkins controllers or GitHub Actions)?
4. Are there alternative approaches we haven't considered?

Your feedback and suggestions on these ideas would be greatly appreciated.