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<[email protected]> 写道： > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4092f2e2-f327-4343-9eec-c55709d87872n%40googlegroups.com.
