In fact, I noticed that we have already included spring-beans as an indirect dependency due to our use of spring-security-web. Is it possible for us to fully replace the usage of commons-beanutils with spring-beans?
在2025年8月2日星期六 UTC+8 00:20:05<[email protected]> 写道： > I did a risk assessment of the various Apache Commons libraries we are > shipping in core. > > --- > > commons-beanutils-1.11.0.jar > Used extensively by Stapler/Jelly and cannot be removed. We're on > version 1.11.0, which doesn't use Commons Lang 3; version 2.0.0-M2 > uses Commons Lang 3. If Commons BeanUtils 2 were to become the only > secure release line, then we would be unable to upgrade without also > including Commons Lang 3 in core (or forking Commons BeanUtils 2 to > remove its dependency on Commons Lang 3). > > commons-collections-3.2.2.jar > Used by core directly only in one outdated location, but used by core > extensively as a transitive dependency of Commons BeanUtils. The > current release doesn't use Commons Lang 3. If a future one did, the > same assessment applies as for Commons BeanUtils 2. > > commons-codec-1.19.0.jar > Not used directly by core. The current release doesn't use Commons > Lang 3. If a future one did, we could remove this library from core > and turn it into a library plugin, rewriting usages in plugins to > either use the library plugin or the Java Platform (similar to what we > are currently doing for Commons Lang 2). > > commons-fileupload2-2.0.0-M4.jar > Used by Stapler and Core. The current release doesn't use Commons Lang > 3. If a future one did, we could possibly rewrite the code to use > standard Java Platform functionality, but that would be tricky due to > compatibility constraints. > > commons-io-2.20.0.jar > Used extensively by core and plugins. The current release doesn't use > Commons Lang 3. If a future one did, we could possibly rewrite the > code to use standard Java Platform functionality, but that be a large > effort. > > We're also shipping our own fork of Jelly/JEXL, but there is no risk > there because we have full control over it. > > --- > > Overall, I think the biggest risk for us is Commons BeanUtils 2. It > would be desirable if we could advocate for Commons BeanUtils 2 to > drop its Commons Lang 3 dependency. We previously (unsuccessfully) > attempted to advocate for Commons Compress to do the same. If such an > advocacy attempt for Commons BeanUtils 2 is similarly unsuccessful, we > might have to eventually add Commons Lang 3 to core, or else fork > Commons BeanUtils 2 to remove its dependency on Commons Lang 3. > -- 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 visit https://groups.google.com/d/msgid/jenkinsci-dev/06f3f4e6-b330-433c-bd3e-74f9008a32b9n%40googlegroups.com.
