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

Allow plugins to declare that they do not use certain implied dependencies

    Details

    • Epic Link:
    • Similar Issues:

      Description

      Filed against core, as there is no component for the maven-hpi-plugin.

      When a plugin has an older core dependency, Jenkins currently adds all plugins detached from core to the plugins' class path, as they may be used by the plugin.

      This can easily lead to circular dependencies, and core has a solution for that in ClassicPluginStrategy (BREAK_CYCLES).

      However, it would be great if plugins could declare that they do not have certain implied dependencies in their own metadata. This has several advantages:

      • Doesn't require core modifications to break dependency cycles
      • Plugins can explicitly not depend on detached plugins, thereby making careful Jenkins administration easier and more stricter dependency handling (refuse to load plugins that don't have all dependencies) viable.

        Attachments

          Issue Links

            Activity

            Hide
            jglick Jesse Glick added a comment -

            Proposal: manifest header / HPI plugin configuration which lets you say that, for example, while your core baseline is 1.625.3, you wish to use the detached list as of 2.60.1 (i.e., you declare that you are not using anything split between those versions). You can easily verify compliance with such a Jenkinsfile like

            buildPlugin(jenkinsVersions: [null, '2.60.1'])

            (Needs to be tested that this will indeed fail in the expected way if the plugin was in fact relying on one of the plugins split between those versions. Certainly compile-time dependencies will fail.)

            Show
            jglick Jesse Glick added a comment - Proposal: manifest header / HPI plugin configuration which lets you say that, for example, while your core baseline is 1.625.3, you wish to use the detached list as of 2.60.1 (i.e., you declare that you are not using anything split between those versions). You can easily verify compliance with such a Jenkinsfile like buildPlugin(jenkinsVersions: [ null , '2.60.1' ]) (Needs to be tested that this will indeed fail in the expected way if the plugin was in fact relying on one of the plugins split between those versions. Certainly compile-time dependencies will fail.)
            Hide
            jglick Jesse Glick added a comment -

            Baptiste Mathus are you actually working on this?

            My proposal of 2017-07-07 would probably be more practical for plugins using

            buildPlugin(configurations: buildPlugin.recommendedConfigurations())
            
            Show
            jglick Jesse Glick added a comment - Baptiste Mathus are you actually working on this? My proposal of 2017-07-07 would probably be more practical for plugins using buildPlugin(configurations: buildPlugin.recommendedConfigurations())
            Hide
            jglick Jesse Glick added a comment -

            form-element-path #8 is an example of where this would be helpful.

            Show
            jglick Jesse Glick added a comment - form-element-path #8 is an example of where this would be helpful.

              People

              • Assignee:
                Unassigned
                Reporter:
                danielbeck Daniel Beck
              • Votes:
                1 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated: