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<[email protected]> 写道： > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/febaef90-375e-46b9-9857-4fa1ed6b6267n%40googlegroups.com.
