- 07 9月, 2011 9 次提交
-
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Christoph Kutzinski 提交于
-
由 Christoph Kutzinski 提交于
[JENKINS-8383] Record fingerprints for parent POMs, too
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
- 06 9月, 2011 1 次提交
-
-
由 olivier lamy 提交于
-
- 05 9月, 2011 4 次提交
-
-
由 Nicolas De loof 提交于
Fix for JENKINS-10443: Added way to mark all plugins to be updated at onc
-
由 Nicolas De loof 提交于
[JENKINS-3727] Read jar manifest to detect the maven version
-
由 OHTAKE Tomohiro 提交于
-
由 Drew Repasky 提交于
-
- 04 9月, 2011 1 次提交
-
-
由 Stephan Pauxberger 提交于
parents
-
- 03 9月, 2011 2 次提交
-
-
由 Stephan Pauxberger 提交于
-
由 Seiji Sogabe 提交于
-
- 02 9月, 2011 2 次提交
-
-
由 Kohsuke Kawaguchi 提交于
-
由 Dean Yu 提交于
Introduce a Jenkins.RUN_SCRIPTS permission
-
- 01 9月, 2011 5 次提交
-
-
由 Ryan Campbell 提交于
-
由 Ryan Campbell 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Andrew Bayer 提交于
project pages.
-
- 31 8月, 2011 3 次提交
-
-
由 Ryan Campbell 提交于
-
由 dty 提交于
-
由 dty 提交于
-
- 30 8月, 2011 13 次提交
-
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 dty 提交于
dependency graph. This functionality is enabled through a feature flag, hudson.tasks.Fingerprinter.enableFingerprintsInDependencyGraph, which is off by default. - Rebuild the dependency graph as part of each fingerprint action. Fingerprinter.buildDependencyGraph adds information to the dependency graph for projects found in fingerprint records. Since the dependency graph is based on project, once a relationship is established between two projects, we can skip scanning subsequent builds of the projects. Entries in the graph added by the fingerprinter action will never automatically trigger downstream builds. core/src/main/java/hudson/tasks/Fingerprinter.java - When reporting dependency changes, don't consider builds that no longer exist. This handles issues when projects are renamed, and new projects are created using the same name, causing the change to point to incorrect builds. core/src/main/java/hudson/model/AbstractBuild.java - Tests. test/src/test/java/hudson/tasks/FingerprinterTest.java
-
由 Kohsuke Kawaguchi 提交于
Conflicts: core/src/main/java/hudson/LocalPluginManager.java
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
Max Spring discovered a stack overflow in http://jenkins.361315.n4.nabble.com/channel-example-and-plugin-classes-gives-ClassNotFoundException-td3756092.html that pointed this call into thread context classloader (TCL) as the culprit. Independently, Paul Sandoz discovered the same issue in our products. If TCL is another classloader that delegates to UberClassLoader (UCL), this code causes infinite recursion. And moreover, given the goal of UCL, it seems wrong that this class is changing behaviour based on contextual information like TCL. In looking at 4de81f1e, the change was introduced to make sure XStream unmarshalling invoked from Plugin.start() would see the classes in that plugin. This was an issue back then when plugins are prepared and loaded one by one, as UCL didn't have visibility into plugins being prepared. But in the current Jenkins, classloaders for all the plugins are prepared, before any plugin gets started, so by the time Plugin.start() runs, UCL is fully functioning. Therefore, there's no need to consult TCL for the purpose of resolving its own classes. I could have also removed the code that sets TCL, but because some libraries often depend on TCL and doesn't properly look at caller class, I'm leaving it in, even though it's generally a bad practice to rely on TCL in multi-classloader apps like Jenkins
-