[JENKINS-29068] Split Groovy out of core

[timja]

Problem Definition

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.

Proposal

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):

Impact

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.

Open Questions

• 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?

Participants

TODO

---

Originally reported by jglick, imported from: Split Groovy out of core

• status: Open
• priority: Major
• resolution: Unresolved
• imported: 2022/01/10

[timja]

jglick:

May also need to offer version-specific script-security bindings.

[timja]

danielbeck:

Overall/RUN_SCRIPTS looks like something that could be moved into the plugin.

[timja]

jglick:

Do not think so. AdminWhitelistRule.doSubmit checks it. Anyway the concept of the permission is valid independent of any particular scripting language implementation used to access the internal APIs.

[timja]

jglick:

Can we get away with…

If that is the best we can do, why not? Increases download size a little but oh well.

how will this impact script-security plugin?

Potentially the sandbox subsystem needs to be split into a separate plugin per Groovy major release. TBD.

Would they get an implied dependency

Yes that is how plugin splitting works.

How can plugins choose their Groovy version?

Normal plugin dependency mechanism.

What about Groovy views in plugins? Would they get the old 1.x Groovy by default

Yes, just like plugin splitting generally.

Would this tie the plugin-internal Groovy version to the plugin-external Groovy version?

Yes. Should not be a problem that I can see. There is just a task to switch the dep from 1.x to 2.x or 2.x to 3.x and retest.

[timja]

danielbeck:

Yes. Should not be a problem that I can see. There is just a task to switch the dep from 1.x to 2.x or 2.x to 3.x and retest.

Right, so we'd be offloading the Groovy update from core into plugins. There would be no way for users to choose their own "System Groovy" version. This is good to know.

[timja]

danielbeck:

How can plugins choose their Groovy version?

Normal plugin dependency mechanism.

Could you elaborate on that? Would plugins have a dependency on the detached plugin, or the module? How'd they get different versions of Groovy when there's only one plugin?

[timja]

jglick:

Would plugins have a dependency on the detached plugin

Yes.

How'd they get different versions of Groovy when there's only one plugin?

You can create distinct wrapper plugins for each Groovy major release (whatever you think the incompatible change boundary is—probably 1.x to 2.x to 3.x).

[timja]

batmat:

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?

[timja]

martinb3:

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.

[timja]

jglick:

martinb3 whatever you are asking for, I doubt it is blocked by this task, or would be helped by implementing this task.

[timja]

bence_takacs:

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

[timja]

danielbeck:

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.

[timja]

[Originally related to: JENKINS-35514]