Status: Open (View Workflow)
Currently Jenkins embeds a distribution of Groovy into "core" for a variety of scripting and management tasks. This version of Groovy is locked into core in such a way that users cannot upgrade Groovy independently from Jenkins itself. If the Jenkins-bundled version were upgraded to a different major version, it may break users' custom scripts as well as plugins that use Groovy due to API changes.
For ease of maintenance and modularity it would be useful to split Jenkins' use of Groovy into a library plugin; different clients could request 1.x and 2.x simultaneously by using different versions of the library, etc.
Stuff in core using Groovy that would need to either be put in this library (if infrastructure for other features) or put in another plugin depending on it (if first-class features themselves):
The following Jenkins core user features make use of Groovy scripting:
- /script console. Probably easy enough. (Remember TEXTAREA.script in behavior.js!)
- init.groovy (and BootFailure). May be tricky since this has to run early in startup.
- Groovy CLI commands. Probably easy.
- Remoting diagnostics. Related to /script?
These will need to be moved into a new, bundled plugin, using the currently bundled Groovy version. Existing plugins would get an implied dependency to this 'detached' plugin like the existing mechanism. Using a newer parent POM version and an explicit dependency, they can change which version of Groovy they get on their classpath. This affects plugin internals and any user-level scripting equally, so plugins determine which Groovy version they offer their users.
Other parts are more related to Jenkins internals and would be handled by a module:
- Groovy views, e.g. GlobalSecurityConfiguration/index.groovy. Means stapler-groovy needs to be loaded externally.
- Security realm customizations (SecurityFilters.groovy / SecurityRealm.createFilter(…)?). These should be in plugins anyway.
- Can we get away with bundling a version of Groovy that isn't made available to plugins for features like init.groovy? Do we want this? May we even need this?
- If we're moving Groovy into a separate plugin ("Groovy Scripting Support" or so), how will this impact script-security plugin?
- How will this impact existing plugins? Would they get an implied dependency to the version of the library that provides the old 1.8.x Groovy currently bundled?
- How can plugins choose their Groovy version? Would that be a global option to Jenkins (which may make migrating terribly complex…)?
- What about Groovy views in plugins? Would they get the old 1.x Groovy by default unless defining a newer release of the Groovy library? Would they never get a new Groovy release?
- Would this tie the plugin-internal (Groovy views) Groovy version to the plugin-external (used by users' scripts) Groovy version?
- is blocked by
JENKINS-49555 Split most of Spring Framework out of core
- is blocking
JENKINS-18349 Allow to use @Grab in a Script Console
JENKINS-30685 Hide core dependencies in plugin classpath
JENKINS-21249 Update Groovy
- is related to
JENKINS-35514 Ability to disable script console
- links to
As someone who has always found the Groovy subsystem cumbersome, if there's any way you could expose the functionality via plugin, for those of us that would prefer to use other languages or interfaces, I would love to see Groovy moved out of core into a plugin. If the functionality was available via plugin, folks could write other interfaces into other languages or even other protocols like RESTful HTTP. It always drove me crazy that I couldn't map the Groovy API to the classes, methods, and interfaces to the Jenkins CORE API or Jenkins plugins.
martinb3 whatever you are asking for, I doubt it is blocked by this task, or would be helped by implementing this task.
Since it is possible to add different 'Groovy installations': what about putting a dropdown to explicitly define the groovy version everywhere you can write script? (and populate it from 'Groovy installations')
When implementing this, do not forget to consider general @Grape support JENKINS-42307
Since it is possible to add different 'Groovy installations':
Groovy plugin functionality has nothing to do with this issue (see 'Impact' section). None of the impacted features launch an external Groovy process.
Shouldn't btw this proposal be linked to https://issues.jenkins-ci.org/browse/JENKINS-31035 because having a way to deprecate many things Groovy in core might proove very useful isn't it?