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

Fix comparison of incremental versions to snapshots

    • Icon: Bug Bug
    • Resolution: Won't Fix
    • Icon: Major Major
    • lib-version-number
    • None

      Suppose you have a plugin A with an incremental version of 1.1-rc100.etc, a plugin B depending on A in that version, and a plugin C also depending on A in that version, but additionally depending on B. Now you wish to test a matching change between A and C. So you edit A and build it, producing 1.1-SNAPSHOT, and change C’s POM to depend on that. But some functional tests (at least InjectedTest.testPluginActive) will fail, because the Jenkins plugin manager refuses to load B: it considers 1.1-SNAPSHOT to be older than the expressed dependency version, 1.1-rc100.etc.

      While in general we do not really know whether a snapshot is older or newer than anything else in its version range, since it could have been built from anything, it is more convenient to assume that it is relatively new.

      Maven’s ComparableVersion does consider the snapshot to be newer, but lib-version-number currently does not. We prefer to have our library, and thus Jenkins core and associated tooling like maven-hpi-plugin, match Maven’s semantics wherever applicable.

          [JENKINS-51594] Fix comparison of incremental versions to snapshots

          Jesse Glick added a comment -

          One workaround would be for hpi:run to define hudson.PluginWrapper.dependenciesVersionCheck.enabled=false.

          A more precise workaround would be for PluginWrapper.resolvePluginDependencies to just log warnings, rather than print PluginWrapper.obsoleteCore or PluginWrapper.obsolete or PluginWrapper.disabledAndObsolete, when either the requested or actual version is a SNAPSHOT (naked or timestamped), since in these cases

          • We cannot guarantee a precise comparison.
          • This should never happen in production installations anyway, only during local development.

          Jesse Glick added a comment - One workaround would be for hpi:run to define hudson.PluginWrapper.dependenciesVersionCheck.enabled=false . A more precise workaround would be for PluginWrapper.resolvePluginDependencies to just log warnings, rather than print PluginWrapper.obsoleteCore or PluginWrapper.obsolete or PluginWrapper.disabledAndObsolete , when either the requested or actual version is a SNAPSHOT (naked or timestamped), since in these cases We cannot guarantee a precise comparison. This should never happen in production installations anyway, only during local development.

          Jesse Glick added a comment -

          Workaround in JENKINS-52665 seems to suffice, and changing semantics of this library seems too risky.

          Jesse Glick added a comment - Workaround in JENKINS-52665 seems to suffice, and changing semantics of this library seems too risky.

            jglick Jesse Glick
            jglick Jesse Glick
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: