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

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

      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.

          [JENKINS-28942] Allow plugins to declare that they do not use certain implied dependencies

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

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

          Jesse Glick added a comment -

          batmat are you actually working on this?

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

          buildPlugin(configurations: buildPlugin.recommendedConfigurations())
          

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

          Jesse Glick added a comment -

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

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

          Oleg Nenashev added a comment -

          No longer relevant for Java 11 GA

          Oleg Nenashev added a comment - No longer relevant for Java 11 GA

          Jesse Glick added a comment -

          This issue has nothing to do with Java versions. Maybe you are referring to JENKINS-55681?

          Jesse Glick added a comment - This issue has nothing to do with Java versions. Maybe you are referring to JENKINS-55681 ?

          Oleg Nenashev added a comment -

          jglick is was in the EPIC for Java 11 support, likely because of the JAXB API plugin. I just moved it out of the epic

          Oleg Nenashev added a comment - jglick is was in the EPIC for Java 11 support, likely because of the JAXB API plugin. I just moved it out of the epic

            Unassigned Unassigned
            danielbeck Daniel Beck
            Votes:
            1 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated: