When speaking of migrating Jenkins to Jakarta EE/jakarta.servlet api, a number of Jenkins plugins depends on the javax.servlet api, either in their code or in their dependencies. They will need to migrate too, except there is an automatic compatibility or migration tool like "<Loader *jakartaConverter*="TOMCAT" />".
Perhaps a first list of plugins to migrate could be made by looking usage of javax.servlet.http.HttpServletRequest and other classes in plugins with https://github.com/jenkins-infra/usage-in-plugins For one, the monitoring plugin 1.x depends on the javax.servlet api. I can migrate it to the jakarta.servlet api in monitoring plugin 2.x including upgrade of dependency. And I suppose that "jenkins.version" in pom.xml of the plugin could be used to set the Jenkins required version of the migrated version of the plugin. In case that the plugin is not upgraded at the same time that Jenkins is upgraded by the user, the plugin will probably break by throwing ClassNotFound / NoClassDefFound, for example when loading the PluginImpl class in the monitoring plugin. Emeric Le samedi 11 mai 2024 à 20:20:06 UTC+2, m...@basilcrow.com a écrit : > While still in milestone status, Commons FileUpload 2.x is being > recommended on the project's home page > <https://commons.apache.org/proper/commons-fileupload/> and GitHub page > <https://github.com/apache/commons-fileupload?tab=readme-ov-file#getting-the-latest-release>, > > and hopefully it will reach GA this year. The Spring 5.3.x EOL > <https://spring.io/blog/2024/03/01/support-timeline-announcement-for-spring-framework-6-0-x-and-5-3-x> > > will likely push the whole Java ecosystem toward Java EE 9+. > > A custom fork of an actively maintained upstream project is a maintenance > burden. My prototype shows that we can maintain compatibility with plugins > across the package rename with a handful of bridge methods. Once those > (few) plugins are migrated to the new package name, the bridge methods can > be deleted, resulting in a lateral move in API surface area (removal of 1.x > and addition of 2.x) rather than an increase (addition of 2.x to the > existing 1.x). > > In the long term, API surface area can be decreased by removing this > library altogether. Multipart file upload is built into the servlet spec > since 3.1 via the HttpServletRequest#getPart() > <https://javadoc.io/doc/jakarta.servlet/jakarta.servlet-api/latest/jakarta.servlet/jakarta/servlet/http/HttpServletRequest.html#getPart(java.lang.String)> > > API. That is a bit of a more involved project (in the sense of being less > of a mechanical rename and more of a logical rewrite of the relevant code) > to redesign the relevant Jenkins APIs in Stapler and core and migrate core > and plugins to these new APIs. A medium-term migration from Commons > FileUpload 1.x to 2.x in no way precludes this long-term strategy. > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/46bb5f18-91f7-4c71-bcb7-29d7039fca54n%40googlegroups.com.
