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

Fix comparison of incremental versions to snapshots

    Details

    • Similar Issues:
    • Epic Link:

      Description

      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.

        Attachments

          Issue Links

            Activity

            Hide
            jglick 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.
            Show
            jglick 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.

              People

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

                Dates

                • Created:
                  Updated: