feat(java): Require Jenkins core 2.492.3 and Java 17

[gounthar]

Hello log-parser developers! 👋

This is an automated pull request created by the Jenkins Plugin Modernizer tool. The tool has applied the following recipes to modernize the plugin:

Upgrade to the next major parent version (5.X) requiring Jenkins 2.492 and Java 17

io.jenkins.tools.pluginmodernizer.UpgradeNextMajorParentVersion

Upgrade to the next major parent version (5.X) requiring Jenkins 2.492 and Java 17.

Why Upgrade to Java 17 and Jenkins 2.479.x?

• Embrace Java 17 LTS Stability: Benefit from long-term support with modern language features that improve development practice and plugin performance.

• Harness Jenkins 2.479.x Innovations: Stay aligned with the latest features and stability improvements, ensuring smooth integration and future-proofing.

• Enhance Security: Protect your plugin with up-to-date security fixes from both Java 17 and Jenkins core improvements.

• Align with the Community: Keep pace with ecosystem shifts towards Java 17, ensuring compatibility and expanding your plugin's user base.

• Enjoy a Better Developer Experience: Make the most of advanced tooling support and simplified dependency management with Java 17's enhancements.

Removing developers Tag from pom.xml

Jenkins no longer requires the developers tag in pom.xml, as the developers section was traditionally used to list individuals responsible for the plugin.
Instead, Jenkins now uses the Repository Permission Updater (RPU) to manage permissions and developer information.

Benefits of Removing developers Tag:

• Simplification: Removes unnecessary metadata from the pom.xml, resulting in a cleaner and more maintainable file.
• Consistency: Centralizes developer information management through the RPU, minimizing discrepancies.
• Security: Utilizes the RPU's controlled permission management, enhancing the security of artifact deployments.

Removing the developers tag aligns with modern Jenkins infrastructure standards and prevents outdated or redundant developer information from being included in plugin metadata.

JEP-227: Replace Acegi Security with Spring Security

Migrating Jenkins plugin code from Acegi Security to Spring Security is important for several reasons:

• Security updates: Spring Security is the modern, actively maintained successor to Acegi Security, providing up-to-date security features and patches.
• Compatibility: Jenkins core version 2.266 and later have replaced Acegi Security with Spring Security, so plugins need to be updated to remain compatible with newer Jenkins versions.
• Eliminating false positives: Security scanners often flag the outdated Acegi Security library as vulnerable, causing unnecessary concerns and exemption requests in security-conscious organizations.
• Reducing technical debt: The Acegi Security code in Jenkins was written over 13 years ago and has barely been touched since, making it difficult to maintain and understand.
• Access to modern features: Spring Security offers more current security implementations and features that weren't available in Acegi Security.
• Community support: With the Jenkins ecosystem moving to Spring Security, plugins using the newer library will benefit from better community support and compatibility with other plugins.
• Simplified API: The migration offers an opportunity to introduce a new simplified security API in Jenkins, potentially making it easier for plugin developers to work with security-related functions.

By migrating to Spring Security, plugin developers ensure their code remains compatible with current Jenkins versions, benefit from modern security features, and contribute to a more secure and maintainable Jenkins ecosystem.

Summary

By upgrading, you'll be positioning your plugin at the forefront of performance, security, and user satisfaction. We encourage you to explore these updates and provide feedback. Let's continue to build a robust Jenkins ecosystem together!

[gounthar]

The check failure is due to the maven build still using jdk11. 🤷
This builds fine on my machine and on the infra.

The build could not read 1 project -> [Help 1]
Error:    
Error:    The project org.jenkins-ci.plugins:log-parser:2.3.8-SNAPSHOT (/home/runner/work/log-parser-plugin/log-parser-plugin/pom.xml) has 1 error
Error:      Unknown packaging: hpi @ line 13, column 16
Error:  
Error:  To see the full stack trace of the errors, re-run Maven with the -e switch.
Error:  Re-run Maven using the -X switch to enable full debug logging.
Error:  
Error:  For more information about the errors and possible solutions, please read the following articles:
Error:  [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
Error: Process completed with exit code 1.

[hypery2k]

@gounthar could rebase your changes to latest develop? Should work now

thanks

[gounthar]

All the check failures seem to be related to them still running with Java 11. I encountered a similar issue with another plugin recently and had to reconfigure the security scan. 🤷

[hypery2k]

the build is actually failing, like the orther PRs too with this error:

Unknown packaging: hpi @ line 13, column 16

Seems an issue with org.jenkins-ci.plugins:plugin v5, see #164

[hypery2k]

build is failing

[hypery2k]

ok, seems Github Runner issue, will merge it and try to resolve it later

[gounthar]

Thanks a lot.
Unfortunately, the GitHub Action still runs with JDK11. :'(

[hypery2k]

had to update the maven wrapper, Release 2.5.0: https://github.com/jenkinsci/log-parser-plugin/releases/tag/v2.5.0

[gounthar]

Great, thanks. 🤗