- 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
- This really has to be controlled by either a system property or a CLI parameter as we cannot guarantee that any path
specified in a configuration file in JENKINS_HOME will be valid on another machine where the JENKINS_HOME is mounted
- Obviously Jenkins does not currently support fully starting two Jenkins instances on the same JENKINS_HOME, so this
fix is to assist in Disaster Recovery (or semi-higher availability) sceanarios where the backup node is being brought
up. In such cases, the node that failed may not have correctly released all its file handles in the backing NFS share
and thus could be blocking the recovery node from starting up.
- An additional use case is where the JENKINS_HOME is stored on a remote disk, e.g. a SAN, etc. and the user wants to
take advantage of the faster local disk to serve the resources from both plugins and Jenkins core. Without this change
only Jenkins core can be relocated outside of JENKINS_HOME (using the '--webroot=...' command line option).
- Ideally we would introduce this into the extras-executable-war module once the system property has had time to soak
(although in an ideal world that module would be agnostic of Jenkins and thus it might not be appropriate there)
The new version of the BCT does not generate stackMap if the original code
did not contain stack maps. Further more the new version takes a
classloader to use so that it can load classes when searching for the
common parent class.
Reproducible for example via HelpLinkTest.testMatrixConfig.
Otherwise have: matrix-project → script-security → matrix-auth → windows-slaves → antisamy-markup-formatter → matrix-project
Tried to come up with a generic way of doing this automatically, but failed.
Just because we bundle a particular build of some plugin does not mean it was built against anything recent,
and for use on older cores it may well need some of those implicit dependencies.
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.
- 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.
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.
kzantow