Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-29068

Split Groovy out of core

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      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

        Attachments

          Issue Links

            Activity

            Hide
            jglick Jesse Glick added a comment -

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

            Show
            jglick Jesse Glick added a comment - May also need to offer version-specific script-security bindings.
            Hide
            danielbeck Daniel Beck added a comment -

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

            Show
            danielbeck Daniel Beck added a comment - Overall/RUN_SCRIPTS looks like something that could be moved into the plugin.
            Hide
            jglick Jesse Glick added a comment -

            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.

            Show
            jglick Jesse Glick added a comment - 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.
            Hide
            jglick Jesse Glick added a comment -

            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.

            Show
            jglick Jesse Glick added a comment - 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.
            Hide
            danielbeck Daniel Beck added a comment -

            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.

            Show
            danielbeck Daniel Beck added a comment - 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.
            Hide
            danielbeck Daniel Beck added a comment -

            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?

            Show
            danielbeck Daniel Beck added a comment - 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?
            Hide
            jglick Jesse Glick added a comment -

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

            Show
            jglick Jesse Glick added a comment - 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).
            Hide
            batmat Baptiste Mathus added a comment -

            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?

            Show
            batmat Baptiste Mathus added a comment - 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?
            Hide
            martinb3 Martin Smith added a comment -

            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.

            Show
            martinb3 Martin Smith added a comment - 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.
            Hide
            jglick Jesse Glick added a comment -

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

            Show
            jglick Jesse Glick added a comment - Martin Smith whatever you are asking for, I doubt it is blocked by this task, or would be helped by implementing this task.
            Hide
            bence_takacs Bence Takacs added a comment -

            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

            Show
            bence_takacs Bence Takacs added a comment - 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
            Hide
            danielbeck Daniel Beck added a comment -

            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.

            Show
            danielbeck Daniel Beck added a comment - 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.

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              jglick Jesse Glick
              Votes:
              8 Vote for this issue
              Watchers:
              21 Start watching this issue

                Dates

                Created:
                Updated: