I have been using Jenkins as an automation server for life science research applications for over 10 years and I have always been able to do things outside the DEVOPS field with ease. Active Choices (of which I’m a contributor) and the power of Groovy scripting have been the ‘cryptonite’ for most of this success. But now, I’m against the wall with all the security and UI improvements that new versions of Jenkins (2.361.x+) are imposing on usability. My question is: how do I add external/third party jar libraries for use in Active Choice Groovy scripting? In the Jenkins 2.222.x past, there were a number of ways to do that, but all have evaporated under the Jenkins security and JDK11 burden.
The Grape @Grab annotation is blocked from all Groovy script, additional classpath options have been eliminated everywhere, and JDK11 has eliminated the java.ext.dirs as a place for jars that can be in-scope for the JVM.
All these were options that I used to add UI components, SQL-DB functionality and image processing capabilities to freestyle job forms. After spending an entire day trying to reconstitute this functionality in ‘new Jenkins’ on my own, I hope one of the ‘new Jenkins’ sages has an answer for me.
Jenkins was an unknown automation server for research/data science applications, but it could always deliver. I have a proven record of 10 years to show that but now, I’m not so sure. Maybe I should stick with Jenkins v2.222 or move on with the Python workflow engineers.
Maybe it is time to add those jar files and other features within Jenkins plugins, rather than adding them as extra jar files?
We’ve certainly appreciated all your contributions to the Jenkins project and your contributions to the use of continuous integration and continuous delivery in data science and bioinformatics.
You could consider moving to Jenkins 2.346.3 with Java 8 as a first step, then look at the transition to Java 11 and Jenkins 2.361.4 or Jenkins 2.375.1 as a second step.
@MarkEWaite thank you for the feedback. I indeed am thinking that this is the way forward too. For the immediate future, deploy the last Jenkins LTS supporting Java 8, and then look into something similar to what Baptiste Mathus and others did with the JAXB Jenkins plugin to provide the JAXB library to other Jenkins plugins in the form of a plugin-to-plugin dependency.
Had similar problems when updating Jenkins Enterprise, as Jenkins runs with Java11 now.
Use this in jenkins.xml to expand the classpath for thirdparty jars (jdbc …), here an example
running on Windows.
-cp "%BASE%\thirdpartyjars\*";"%BASE%\cloudbees-core-cm.war" executable.Main
Thank you for pointing this out @Rebse ! This is also the reason that I need to expand the classpath.
I gave your suggestion a try and it appears to work!
Much appreciated! Time for some more testing with Active Choices!
Your try before the edit didn’t work because if using
-cp is simply ignored!
Just put the jenkins.war to classpath like in my example and delete
Indeed, that is the key point! Thank you!
Without using the -jar option but adding the jenkins war to the java -cp option expands the classpath of Jenkins itself and I can now use my third-party libraries. The other important piece in your example code is the name of the main class to call. That was not obvious to me, and I was incorrectly using hudson.Main.
The correct class name is executable.Main
In my case, I use the OS version of Jenkins and the command is something like:
java -Xrs -Xmx256m -cp ".;C:\Windows\Sun\Java\lib\ext\*;D:\DEVTOOLS\Jenkins\jenkins.war" -Dorg.kohsuke.stapler.jelly.CustomJellyContext.escapeByDefault="false" executable.Main