I see. As stated above Spring Security 5.x EOL deadline. We have until August 31, 2024 to move to jakarta api.
To be honest, I have doubts about whether commons-uploadfile can release the 2.x GA version within 3 months. Then we have to think about a problem in advance. If there is no 2.x GA version yet, do we ship a snapshot version of commons-uploadfile 2.x in Jenkins? In addition, I tried to count the code size of commons-uploadfile and found that there were only 41 valid java files and 2503 lines of valid code. (using the cloc tool analysis, a npm package). Not very huge. The maintenance burden of using the fork version as a transitional stage in the short term will not be too heavy. If we once reach a consensus on the long-term goal - to remove the dependency on commons-uploadfile in jenkins. So as a short-term solution, forking and maintaining a commons-uploadfile seems to be a low cost solution. Focus more engineering energy on long-term goals. I am willing to contribute code to achieve this long-term goal. 在2024年5月12日星期日 UTC+8 02:20:06<m...@basilcrow.com> 写道： > 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/febaef90-375e-46b9-9857-4fa1ed6b6267n%40googlegroups.com.
