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

            jglick Jesse Glick created issue -
            jglick Jesse Glick made changes -
            Field Original Value New Value
            Link This issue is blocking JENKINS-21249 [ JENKINS-21249 ]
            kohsuke Kohsuke Kawaguchi made changes -
            Labels groovy split-plugins-from-core 2.0 groovy split-plugins-from-core
            jglick Jesse Glick made changes -
            Link This issue is blocking JENKINS-30685 [ JENKINS-30685 ]
            rtyler R. Tyler Croy made changes -
            Description 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):

            * {{/script}} console. Probably easy enough. (Remember {{TEXTAREA.script}} behavior!)
            * Groovy views. Means {{stapler-groovy}} needs to be loaded externally.
            * {{init.groovy}} (and {{BootFailure}}). May be tricky since this has to run early in startup.
            * Groovy CLI commands. Probably easy.
            * Security realm customizations. These should be in plugins anyway.
            * Remoting diagnostics. Related to {{/script}}?
            h1. Problem Definition

            Groovy's locked into the core distribution and that prevents users from upgrading Groovy without the Jenkins core itself being upgraded.

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

            * {{/script}} console. Probably easy enough. (Remember {{TEXTAREA.script}} behavior!)
            * Groovy views. Means {{stapler-groovy}} needs to be loaded externally.
            * {{init.groovy}} (and {{BootFailure}}). May be tricky since this has to run early in startup.
            * Groovy CLI commands. Probably easy.
            * Security realm customizations. These should be in plugins anyway.
            * Remoting diagnostics. Related to {{/script}}?

            h1. Impact

            h1. Open Questions

            h1. Participants

            h1. References
            jglick Jesse Glick made changes -
            Description h1. Problem Definition

            Groovy's locked into the core distribution and that prevents users from upgrading Groovy without the Jenkins core itself being upgraded.

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

            * {{/script}} console. Probably easy enough. (Remember {{TEXTAREA.script}} behavior!)
            * Groovy views. Means {{stapler-groovy}} needs to be loaded externally.
            * {{init.groovy}} (and {{BootFailure}}). May be tricky since this has to run early in startup.
            * Groovy CLI commands. Probably easy.
            * Security realm customizations. These should be in plugins anyway.
            * Remoting diagnostics. Related to {{/script}}?

            h1. Impact

            h1. Open Questions

            h1. Participants

            h1. References
            h1. Problem Definition

            Groovy's locked into the core distribution and that prevents users from upgrading Groovy without the Jenkins core itself being upgraded, or from using different major releases of Groovy in different plugins.

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

            * {{/script}} console. Probably easy enough. (Remember {{TEXTAREA.script}} behavior!)
            * Groovy views. Means {{stapler-groovy}} needs to be loaded externally.
            * {{init.groovy}} (and {{BootFailure}}). May be tricky since this has to run early in startup.
            * Groovy CLI commands. Probably easy.
            * Security realm customizations. These should be in plugins anyway.
            * Remoting diagnostics. Related to {{/script}}?

            h1. Impact

            h1. Open Questions

            h1. Participants

            h1. References
            rtyler R. Tyler Croy made changes -
            Description h1. Problem Definition

            Groovy's locked into the core distribution and that prevents users from upgrading Groovy without the Jenkins core itself being upgraded, or from using different major releases of Groovy in different plugins.

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

            * {{/script}} console. Probably easy enough. (Remember {{TEXTAREA.script}} behavior!)
            * Groovy views. Means {{stapler-groovy}} needs to be loaded externally.
            * {{init.groovy}} (and {{BootFailure}}). May be tricky since this has to run early in startup.
            * Groovy CLI commands. Probably easy.
            * Security realm customizations. These should be in plugins anyway.
            * Remoting diagnostics. Related to {{/script}}?

            h1. Impact

            h1. Open Questions

            h1. Participants

            h1. References
            h1. Problem Definition

            Currently Jenkins embeds a distribution of [Groovy|http://groovy-lang.org] into "core" for a variety of scripting and management tasks. This version of Groovy is locked into core in such a way that prevents users from upgrading Groovy without upgrading Jenkins itself. This prevents users and plugin developers from taking advantage of improvements made in Groovy and inhibits the Jenkins developer team from upgrading Groovy in core since it "touches" so many facets of the application, making an upgrade far ore risky than it should be.

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

            * {{/script}} console. Probably easy enough. (Remember {{TEXTAREA.script}} behavior!)
            * Groovy views. Means {{stapler-groovy}} needs to be loaded externally.
            * {{init.groovy}} (and {{BootFailure}}). May be tricky since this has to run early in startup.
            * Groovy CLI commands. Probably easy.
            * Security realm customizations. These should be in plugins anyway.
            * Remoting diagnostics. Related to {{/script}}?

            h1. Impact

            h1. Open Questions

            h1. Participants

            h1. References
            danielbeck Daniel Beck made changes -
            Description h1. Problem Definition

            Currently Jenkins embeds a distribution of [Groovy|http://groovy-lang.org] into "core" for a variety of scripting and management tasks. This version of Groovy is locked into core in such a way that prevents users from upgrading Groovy without upgrading Jenkins itself. This prevents users and plugin developers from taking advantage of improvements made in Groovy and inhibits the Jenkins developer team from upgrading Groovy in core since it "touches" so many facets of the application, making an upgrade far ore risky than it should be.

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

            * {{/script}} console. Probably easy enough. (Remember {{TEXTAREA.script}} behavior!)
            * Groovy views. Means {{stapler-groovy}} needs to be loaded externally.
            * {{init.groovy}} (and {{BootFailure}}). May be tricky since this has to run early in startup.
            * Groovy CLI commands. Probably easy.
            * Security realm customizations. These should be in plugins anyway.
            * Remoting diagnostics. Related to {{/script}}?

            h1. Impact

            h1. Open Questions

            h1. Participants

            h1. References
            h1. Problem Definition

            Currently Jenkins embeds a distribution of [Groovy|http://groovy-lang.org] 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.

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

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

            Other parts are more related to Jenkins internals:

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

            h1. 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…)?

            h1. Participants

            TODO
            danielbeck Daniel Beck made changes -
            Description h1. Problem Definition

            Currently Jenkins embeds a distribution of [Groovy|http://groovy-lang.org] 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.

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

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

            Other parts are more related to Jenkins internals:

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

            h1. 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…)?

            h1. Participants

            TODO
            h1. Problem Definition

            Currently Jenkins embeds a distribution of [Groovy|http://groovy-lang.org] 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.

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

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

            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.

            h1. 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?

            h1. Participants

            TODO
            danielbeck Daniel Beck made changes -
            Description h1. Problem Definition

            Currently Jenkins embeds a distribution of [Groovy|http://groovy-lang.org] 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.

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

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

            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.

            h1. 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?

            h1. Participants

            TODO
            h1. Problem Definition

            Currently Jenkins embeds a distribution of [Groovy|http://groovy-lang.org] 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.

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

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

            h1. 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?

            h1. Participants

            TODO
            kohsuke Kohsuke Kawaguchi made changes -
            Labels 2.0 groovy split-plugins-from-core 2.0-rejected groovy split-plugins-from-core
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 163934 ] JNJira + In-Review [ 181438 ]
            danielbeck Daniel Beck made changes -
            Link This issue is related to JENKINS-35514 [ JENKINS-35514 ]
            jglick Jesse Glick made changes -
            Link This issue is blocking JENKINS-18349 [ JENKINS-18349 ]
            jglick Jesse Glick made changes -
            Remote Link This issue links to "PR 3006 (Web Link)" [ 19308 ]
            jglick Jesse Glick made changes -
            Remote Link This issue links to "PR 3184 (Web Link)" [ 19329 ]
            jglick Jesse Glick made changes -
            Link This issue is blocked by JENKINS-49555 [ JENKINS-49555 ]

              People

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

                Dates

                Created:
                Updated: