- 07 9月, 2011 1 次提交
-
-
由 Kohsuke Kawaguchi 提交于
-
- 30 8月, 2011 17 次提交
-
-
由 Kohsuke Kawaguchi 提交于
-
由 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
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
- 29 8月, 2011 8 次提交
-
-
由 Ryan Campbell 提交于
-
由 Kohsuke Kawaguchi 提交于
not exposing the setBuiltOnStr to arbitrary external methods. It's really only for internal consumption.
-
由 Richard Mortimer 提交于
-
由 Richard Mortimer 提交于
Remove the shadow copy of buildOn from MavenBuild.java and move the setter to AbstractBuild to allow MavenModuleSetBuild.java to continue to set the build node.
-
由 Kohsuke Kawaguchi 提交于
following up tweaks to the previous commit, and explaining what we don't do so that future versions don't inadvertently mess up them
-
由 Tim Pizey 提交于
-
由 Mark Field 提交于
Add displayName and description as further optional tags that can be submitted as part of an External run
-
由 Stefan Wolf 提交于
Use stock gmaven plugin to achieve this
-
- 28 8月, 2011 3 次提交
-
-
由 Christoph Kutzinski 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
- 27 8月, 2011 3 次提交
-
-
由 Kohsuke Kawaguchi 提交于
-
由 olivier lamy 提交于
-
由 Christoph Kutzinski 提交于
fixed serving of JARs if running with hudson-dev:run which was broken since https://github.com/jenkinsci/jenkins/commit/a376eb5832a75d4fb840a9088b37a988582b0965
-
- 28 8月, 2011 1 次提交
-
-
由 Olivier Lamy 提交于
-
- 27 8月, 2011 3 次提交
-
-
由 Olivier Lamy 提交于
Ignore null reporters field in MavenBuild$RunnerImpl.post2 and avoid a NPE. Thanks !
-
由 Richard Mortimer 提交于
The NPE can occur if a build fails during checkout and hence the run phase never gets called. See JENKINS-10831 for an example of this happening.
-
由 dty 提交于
- Added a RenameListener to Fingerprint. When the listener is invoked for renamed projects, it will iterate over all the builds of the project looking for fingerprint actions. If the build was the originator of the fingerprint, the buildPtr is updated; (had to make the name non-final to allow for this). If the build is the consumer of a fingerprint, the usages are updated. core/src/main/java/hudson/model/Fingerprint.java - Expose the fingerprint data inline with the build data in the remote API. The renaming code also uses this method as a convenient way to get the fingerprints for a build. core/src/main/java/hudson/model/AbstractBuild.java - Test. test/src/test/java/hudson/tasks/FingerprinterTest.java
-
- 26 8月, 2011 3 次提交
-
-
由 Nicolas De Loof 提交于
-
由 Kohsuke Kawaguchi 提交于
happen. This happens because the version number isn't computed yet, but we try to put that into HTTP header. Fixing this by making <st:header/> tolerate null in value or name.
-
由 Kohsuke Kawaguchi 提交于
JVM.
-
- 25 8月, 2011 1 次提交
-
-
由 Kohsuke Kawaguchi 提交于
-