Thanks basil, I agree with your idea. I will prepare another PR to modernize the CI system first.
Before that, I checked and compared the code and found that the fork dependency version currently in use should have been built and released from the rebase-2.4 branch, not master. If you also confirm that this is the current situation, could you rename the rebase-2.4 branch to main or master branch, and set it as the default branch? And rename the current master to before-modernize-master-backup branch (or another name to archive it)? 在2024年4月11日星期四 UTC+8 06:27:35<m...@basilcrow.com> 写道： > Hey Bob, thank you for proposing this! > > Jenkins core delivers JSON-lib under the net.sf package namespace, > consumes it itself, and provides it to many consuming plugins. It > looks like Andres Almiray is still maintaining JSON-lib and EZMorph > over at https://github.com/kordamp/json-lib and > https://github.com/kordamp/ezmorph, but these new versions use the > org.kordamp package namespace and depend on Commons Lang 3 — both of > which go against our goal to avoid increasing core API surface area by > exposing additional third-party libraries. > > Ultimately core needs to be able to parse JSON itself, and the Java > Platform does not provide a built-in way to do this. Under the current > architecture, where all core dependencies are exposed to plugins, that > means we can't avoid exposing at least _one_ JSON library to plugins: > the one used by core itself, which is currently JSON-lib under the > net.sf package namespace. Even if we did want to migrate core and > plugins to a newer version of JSON-lib or a different JSON library > (and I'm not sure we do), we'd have to continue to support JSON-lib > under the net.sf package namespace during the transition period at the > very least. > > So your idea of cleaning up our old fork of (net.sf-based) JSON-lib to > at least avoid Commons Lang 2 sounds practical indeed in the short to > medium-term. At least that will allow us to proceed with cleaning up > Commons Lang, even if the JSON mess remains — a problem which can be > dealt with separately, if we ever need to deal with it at all. Another > argument in favor of this proposal is that it is no worse than the > current status quo, but a strict improvement in that it decreases > core's API surface area — without any risk of regression. These > advantages are not insignificant when dealing with such an old > codebase. > > I could support this plan with one minor tweak. As I wrote in another > thread recently, I think modernizing the build and CI system should be > done before any other changes, because it is difficult to review and > test the other changes without a working build and CI system. In part > due to the success of the Jenkins project, the bar for software > development has been raised throughout the industry such that a modern > build and CI system is now considered table stakes. Accordingly, I > think this should be done first, and then the other changes you have > mentioned. So I would kindly request that you first prepare a PR to > update the build to use the latest parent POM and Jenkinsfile. Without > commit access to the repository in question, you won't be able to test > Jenkinsfile changes on ci.jenkins.io, but I can assist with testing > these changes using my permissions. Here are some other core > components that can be used as a reference: > > https://github.com/jenkinsci/bridge-method-injector > https://github.com/jenkinsci/core-annotation-processors > https://github.com/jenkinsci/extensibility-api > https://github.com/jenkinsci/extras-memory-monitor > https://github.com/jenkinsci/jelly > https://github.com/jenkinsci/jenkins-test-harness > https://github.com/jenkinsci/jenkins-test-harness-htmlunit > https://github.com/jenkinsci/lib-access-modifier > https://github.com/jenkinsci/lib-annotation-indexer > https://github.com/jenkinsci/lib-crypto-util > https://github.com/jenkinsci/lib-file-leak-detector > https://github.com/jenkinsci/lib-mock-javamail > https://github.com/jenkinsci/lib-process-utils > https://github.com/jenkinsci/lib-support-log-formatter > https://github.com/jenkinsci/lib-symbol-annotation > https://github.com/jenkinsci/lib-task-reactor > https://github.com/jenkinsci/lib-test-annotations > https://github.com/jenkinsci/lib-version-number > https://github.com/jenkinsci/remoting > https://github.com/jenkinsci/stapler > https://github.com/jenkinsci/winstone > -- 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/4092f2e2-f327-4343-9eec-c55709d87872n%40googlegroups.com.
