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

Refuse to load a plugin if dependencies are disabled or outdated

    XMLWordPrintable

Details

    Description

      According to jglick, Jenkins lets a plugin start even if some of its dependencies are missing.

      Since missing dependencies might only get much later (for example during builds), it's better to let those plugins fail earlier than later.

      Combined with JENKINS-21485, this will make Jenkins boot more reliable and help administrators catch problems more quickly.

      Attachments

        Issue Links

          Activity

            teilo James Nord added a comment -

            This fix seems to cause a regression when using optional dependencies and the variant plugin.
            previously when tagged with OptionalExtension you could use a class that was only in a specific version of a plugin and then the code that depended on the "newer" plugin than was installed would not activate.

            Whilst this is ok for the main running of Jenkins - it causes a massive headache when running tests and depending on a version of a plugin that is using newer optional dependencies than provided by Jenkins (ie previously bundled).

            teilo James Nord added a comment - This fix seems to cause a regression when using optional dependencies and the variant plugin. previously when tagged with OptionalExtension you could use a class that was only in a specific version of a plugin and then the code that depended on the "newer" plugin than was installed would not activate. Whilst this is ok for the main running of Jenkins - it causes a massive headache when running tests and depending on a version of a plugin that is using newer optional dependencies than provided by Jenkins (ie previously bundled).
            danielbeck Daniel Beck added a comment -

            teilo Does this apply to (at)Extension(optional = true) the same way?

            danielbeck Daniel Beck added a comment - teilo Does this apply to (at)Extension(optional = true) the same way?

            teilo see this thread for the full background of the implementation regarding dealing with obsolete optional dependencies.

            vlatombe Vincent Latombe added a comment - teilo see this thread for the full background of the implementation regarding dealing with obsolete optional dependencies.
            teilo James Nord added a comment -

            danielbeck yes - but the (at)Extension(optional = true) has no way to infer a version.
            (infact I can forsee a version of the Variant plugin that allows to specify a specific version of a plugin.)

            Mainly a headache at the moment due to what appears to be a bug in JenkinsRule (or the hpi plugin) and not loading the optional dependencies correctly for dependant plugins. (e.g. something like JENKINS-20412) - but to be investigated and filed separately.

            teilo James Nord added a comment - danielbeck yes - but the (at)Extension(optional = true) has no way to infer a version. (infact I can forsee a version of the Variant plugin that allows to specify a specific version of a plugin.) Mainly a headache at the moment due to what appears to be a bug in JenkinsRule (or the hpi plugin) and not loading the optional dependencies correctly for dependant plugins. (e.g. something like JENKINS-20412 ) - but to be investigated and filed separately.
            jglick Jesse Glick added a comment -

            JenkinsRule (or the hpi plugin) and not loading the optional dependencies correctly for dependant plugins

            I think all you are seeing is that Maven does not traverse transitive dependencies past <optional>true</optional>.

            Anyway I am not sure I am following what issue you are seeing.

            newer optional dependencies than provided by Jenkins (ie previously bundled)

            Are you referring to split plugins, à la ClassicPluginStrategy.DETACHED_LIST? Or what? It is up to the person defining tests to ensure that the plugins available in Maven’s test classpath are mutually compatible; if something is too old, you are obliged to either add <exclusions> for inappropriate dependency trails, or add explicit dependencies on a newer version. Now we may want to provide a friendlier system in the future, but for now that is how it is.

            jglick Jesse Glick added a comment - JenkinsRule (or the hpi plugin) and not loading the optional dependencies correctly for dependant plugins I think all you are seeing is that Maven does not traverse transitive dependencies past <optional>true</optional> . Anyway I am not sure I am following what issue you are seeing. newer optional dependencies than provided by Jenkins (ie previously bundled) Are you referring to split plugins, à la ClassicPluginStrategy.DETACHED_LIST ? Or what? It is up to the person defining tests to ensure that the plugins available in Maven’s test classpath are mutually compatible; if something is too old, you are obliged to either add <exclusions> for inappropriate dependency trails, or add explicit dependencies on a newer version. Now we may want to provide a friendlier system in the future, but for now that is how it is.

            People

              vlatombe Vincent Latombe
              kohsuke Kohsuke Kawaguchi
              Votes:
              6 Vote for this issue
              Watchers:
              11 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: