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

Upgrade sshd-module to use SSHD 2.x

XMLWordPrintable

    • sshd-3.0.4

      Some of the libraries that Jenkins uses (e.g. JGit) have moved on to use SSHD 2.x. This contains breaking changes. But sshd-module still expects SSHD 1.x. The incompatibilities cause either compile-time or runtime 'class not found' errors in Jenkins and its plugins.

      We need to bump our SSHD dependencies to fix this.

      Options:

      • SSHD 2.2.0 (also used by the current release of JGit)
      • SSHD 2.3.0 (the very latest version)

      Affected downstream components:

      • Gerrit Trigger plugin
      • git-server plugin
      • Jenkins Core CLI
      • Remote terminal access plugin
      • ...

          [JENKINS-60902] Upgrade sshd-module to use SSHD 2.x

          Chris Kilding created issue -
          Oleg Nenashev made changes -
          Labels New: sshd
          Oleg Nenashev made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]
          Oleg Nenashev made changes -
          Remote Link New: This issue links to "https://github.com/jenkinsci/sshd-module/pull/33 (Web Link)" [ 24354 ]

          Oleg Nenashev added a comment -

          When the first 2.0 versions were announced, I was a bit hesitant about moving immediately due to compatibility issues. I believe we should move rather sooner than later, so we should definitely start exploring our options to keep compatibility as much as possible.

          > In my experience, the number 1 cause of compilation errors and runtime NoClassDefFoundErrors from this change is that Command and CommandFactory have been moved to a sub-package.

          For this purpose we could create bridge classes in SSHD Module and to extend the moved classes. But we need a full scope of breaking changes to analyze and mitigate the impact

           

          Oleg Nenashev added a comment - When the first 2.0 versions were announced, I was a bit hesitant about moving immediately due to compatibility issues. I believe we should move rather sooner than later, so we should definitely start exploring our options to keep compatibility as much as possible. > In my experience, the number 1 cause of compilation errors and runtime NoClassDefFoundErrors from this change is that  Command  and  CommandFactory  have been moved to a sub-package. For this purpose we could create bridge classes in SSHD Module and to extend the moved classes. But we need a full scope of breaking changes to analyze and mitigate the impact  
          Oleg Nenashev made changes -
          Priority Original: Minor [ 4 ] New: Critical [ 2 ]
          Oleg Nenashev made changes -
          Labels Original: sshd New: compatibility sshd
          Oleg Nenashev made changes -
          Component/s New: cli [ 15624 ]
          Component/s New: gerrit-trigger-plugin [ 15731 ]
          Component/s New: git-server-plugin [ 17613 ]
          Component/s New: remote-terminal-access-plugin [ 17321 ]
          Mark Waite made changes -
          Remote Link New: This issue links to "PR-33 upgrade sshd module to sshd 2.2 (Web Link)" [ 24355 ]

          Mark Waite added a comment -

          This seems like a large enough change to justify setting the major number of the sshd module to 3.0. The prior releases of sshd module did not seem to contain major API breaking changes like this one does.

          Mark Waite added a comment - This seems like a large enough change to justify setting the major number of the sshd module to 3.0. The prior releases of sshd module did not seem to contain major API breaking changes like this one does.

            ifernandezcalvo Ivan Fernandez Calvo
            chriskilding Chris Kilding
            Votes:
            1 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: