- 15 4月, 2014 2 次提交
-
-
由 Jesse Glick 提交于
-
由 Jesse Glick 提交于
-
- 25 3月, 2014 1 次提交
-
-
由 Kohsuke Kawaguchi 提交于
-
- 24 3月, 2014 1 次提交
-
-
由 Jesse Glick 提交于
-
- 22 2月, 2014 1 次提交
-
-
由 Jesse Glick 提交于
[FIXED JENKINS-12124] Occasionally errors loading plugin classes since it is expected that findClass (and findLoadedClass) are called under synchronization. The problem was masked by a blind assumption that an InvocationTargetException was in fact wrapping a ClassNotFoundException. Many thanks to @gotwarlost for demonstrating how to reproduce the problem and diagnosing the cause.
-
- 18 2月, 2014 1 次提交
-
- 04 1月, 2014 1 次提交
-
- 10 12月, 2013 1 次提交
-
-
由 ikedam 提交于
[FIXED JENKINS-19976] Enable plugins to load classes from optionally depending plugins even without restarting after depended ones installed.
-
- 15 11月, 2013 2 次提交
-
-
由 Jesse Glick 提交于
-
由 Jesse Glick 提交于
-
- 26 10月, 2013 1 次提交
-
-
由 Kohsuke Kawaguchi 提交于
Escape hatch to disable bytecode transformation in case this causes other unforeseen problems.
-
- 05 10月, 2013 2 次提交
-
-
由 Jesse Glick 提交于
-
由 Jesse Glick 提交于
-
- 27 8月, 2013 1 次提交
-
-
由 evernat 提交于
-
- 03 8月, 2013 1 次提交
-
-
由 Kohsuke Kawaguchi 提交于
Integrated bytecode-compatibility-transformer that allows core to do signature changes on properties that plugins might depend on. The library performs necessary bytecode transformation to achieve this. The first use of this is to fix plugins that looks for List AbstractProject.triggers, thereby resolving JENKINS-18677. For the time being, I'm not loading such compatibility annotations from plugins, but I did code that in PluginManager. Let's see how this feature work out for a while in the core, and if it looks stable and solid, we'll open it up to plugins at that point.
-
- 08 7月, 2013 1 次提交
-
-
由 Nicolas De Loof 提交于
-
- 08 6月, 2013 1 次提交
-
-
由 Kohsuke Kawaguchi 提交于
- integrated the newer release of remoting - jar caching won't work with class file directory, so plugin WEB-INF/classes are now exploded as WEB-INF/lib/classes.jar (This should also solve the problem of slow plugin extraction in the presene of Anti-virus software on Windows.) - because the structure of the exploded jar file has changed, I changed the up-to-date check timestamp file name to force re-extraction in existing installations.
-
- 20 12月, 2012 1 次提交
-
-
由 Kohsuke Kawaguchi 提交于
This is primarily to mask JavaEE API classes. Mask-Classes itself is insufficient as I described in the comment
-
- 09 12月, 2012 1 次提交
-
-
由 Kohsuke Kawaguchi 提交于
-
- 17 11月, 2012 1 次提交
-
-
由 Jesse Glick 提交于
-
- 16 6月, 2012 1 次提交
-
-
由 Kohsuke Kawaguchi 提交于
I couldn't quite find one place to do this, so it's spread apart somewhat.
-
- 31 5月, 2012 1 次提交
-
-
由 Kohsuke Kawaguchi 提交于
-
- 30 5月, 2012 1 次提交
-
-
由 Kohsuke Kawaguchi 提交于
The actual release needs to happen in a lock step, as the new plugin needs to require yet-to-be-released version of the core. So for the time being it's a snapshot dependency, deployed in the snapshot repository.
-
- 10 2月, 2012 1 次提交
-
-
由 Kohsuke Kawaguchi 提交于
-
- 04 1月, 2012 1 次提交
-
-
由 imod 提交于
-
- 10 10月, 2011 4 次提交
-
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
- 09 9月, 2011 4 次提交
-
-
由 Kohsuke Kawaguchi 提交于
if the plugin is built with 1.431-SNAPSHOT core, we don't want that to automatically pick up ant & javadoc. We only want that for plugins built against 1.430 or earlier.
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
- 30 8月, 2011 1 次提交
-
-
由 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
-
- 24 7月, 2011 1 次提交
-
-
由 Christoph Kutzinski 提交于
deleted encoding-less variant of readFirstLine according to https://github.com/jenkinsci/jenkins/commit/4ee8d6890c354e67daeb5f55806c16f6986b32c3#core/src/main/java/hudson/util/IOUtils.java-P13
-
- 23 7月, 2011 1 次提交
-
-
由 Jerome Lacoste 提交于
-
- 18 7月, 2011 1 次提交
-
-
由 Christoph Kutzinski 提交于
-
- 18 6月, 2011 1 次提交
-
-
由 Kohsuke Kawaguchi 提交于
-
- 29 5月, 2011 2 次提交
-
-
由 Nigel Magnay 提交于
Just import changes, from hudson.model.Jenkins -> jenkins.model.Jenkins, and Javadoc comments. Signed-off-by: NNigel Magnay <nigel.magnay@gmail.com>
-
由 Nigel Magnay 提交于
Signed-off-by: NNigel Magnay <nigel.magnay@gmail.com>
-