As a part of PR 1847, 3b5424e507 introduced a second invocation to
executeReactor. This is causing a problem in that it exectes
InitMilestone progression twice. If you are looking at
Jenkins.getInitLevel() it will go through STARTED ... COMPLETED once,
then it goes back to STARTED and then go to COMPLETED again.
And this code looks bit odd anyway. Why execute a whole reactor
just to make one method invocation? But I didn't see any discussion of
this in PR 1847.
This change fixes this oddity by making this a part of the main
(and sole) initialization reactor session. It's not clear what
milestone should be the pre-requisite, but given that it's only looking
at dependency chain, PLUGINS_PREPARED should be adequate.
Of course the import being used is in a package name that is reserved for artifacts produced by a JSR... and the JSR that the dependency is claiming to come from has not actually published anything... thus whoever produced the artifact has broken the JSR policy... and it is also not safe for us to actually use these annotations as we do not know what a JSR may change on the road to actually providing this... but that is a war for a different PR
- Also expose via servlet context parameter of same name to allow multiple instances of Jenkins in the same servlet container to have different directories
- As we are no longer a constant, change the system property to camelCase
Squashed commit of the following:
commit f2c6ad272f
Author: Sam Van Oort <samvanoort@gmail.com>
Date: Thu Aug 20 18:28:09 2015 -0400
After much discussion, just remove the helper method to let a plugin manager override easily get instance of the PluginManager
commit a96f933d8d
Author: Sam Van Oort <samvanoort@gmail.com>
Date: Thu Aug 20 16:59:07 2015 -0400
Add javadocs and restrict access on the PluginManagerStaplerOverride getManager method
commit 7e1facf887
Author: Sam Van Oort <samvanoort@gmail.com>
Date: Thu Aug 20 12:50:47 2015 -0400
Simplify plugin manager test using @TestExtension
commit b9f2841f6d
Author: Sam Van Oort <samvanoort@gmail.com>
Date: Thu Aug 20 10:32:49 2015 -0400
Modify the Since version for pluginmanager overrides
commit 3af45ce579
Author: Sam Van Oort <samvanoort@gmail.com>
Date: Thu Aug 20 10:28:14 2015 -0400
Add test for PluginManagerStaplerOverride
commit 7864094565
Author: Sam Van Oort <samvanoort@gmail.com>
Date: Mon Aug 17 20:59:33 2015 -0400
Changes from review, mostly comments and rename of class
commit 1c23f086ec
Author: Sam Van Oort <samvanoort@gmail.com>
Date: Mon Aug 17 12:58:07 2015 -0400
Cleanup for PluginManager extensibility/UI overrides
commit e105a13bcf
Author: Sam Van Oort <samvanoort@gmail.com>
Date: Fri Aug 14 15:23:07 2015 -0400
Different approach to plugin manager UX pluggability, using Extension and StaplerOverridable
commit 81f21fba08
Author: Sam Van Oort <samvanoort@gmail.com>
Date: Thu Aug 13 21:32:45 2015 -0400
Initial round of changes to allow overriding PluginManager
This includes renaming the setTarget method to setUIProxy and defining an interface to retain APIs
Fields have not been mapped through yet as that is still in progress
Also, an AbstractStaplerUIProxy has been defined to delegate Stapler bound calls to the pluginManager
commit eeef666de7
Author: Sam Van Oort <samvanoort@gmail.com>
Date: Wed Aug 5 17:40:50 2015 -0400
Make plugin manager pluggable
Although the plugiun manager was vulnerable getting information
out of Jenkins was harder - however it would still be possible to
do bad things such as reading from /dev/zero on Linux
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.
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.
Kohsuke Kawaguchi