Handling Vastly Outdated Plugins: A Modernization Approach

[gounthar]

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.

[jonesbusy]

I confirm the maven invoker library support passing a different JDK when invoking maven. So yes it could be possible to provide different JDK versions to the tool. My feeling is that is probably more simple to compile locally (without tests). The inconvenience is that the user needs to manage is own JDKs version. Or the tool need to manage those installations (like Jenkins can do (for example download and caching from temurin github organisation the JDKs.

…

On Wed, 24 Jul 2024, 18:08 Bruno Verachten, ***@***.***> wrote: 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 <https://sdkman.io/> 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. — Reply to this email directly, view it on GitHub <#119>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGJTFRHRXJ4BBVKHGKHYW3ZN7GPHAVCNFSM6AAAAABLMZZCBCVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZWHE3TGMRSG4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[gounthar]

I am doing a poc with SDKMAN, but having SDKMAN as a prerequisite does not seem that nice of a requirement. 🙄
We could do that (hopefully) through GitPod though, without having to install anything locally. 🤷