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
            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
                Reporter:
                jglick Jesse Glick
              • Votes:
                8 Vote for this issue
                Watchers:
                19 Start watching this issue

                Dates

                • Created:
                  Updated: