• 2.357

      None of the currently bundled jenkins-module packages actually look like they need to be modules: they do not appear to need to be loaded in the same class loader as jenkins-core.jar, nor to have extensions/services registered early in the startup sequence. As such, they could be made into regular plugins (hpi packaging), and the usual split-plugins.txt registry used to retain compatibility for existing plugins which happen to refer to their classes (InstanceIdentity and SshCommandFactory are the main examples).

      As an aside refiled as JENKINS-57023.

          [JENKINS-55582] Convert modules to plugins

          Oleg Nenashev added a comment -

          I think it needs a JEP. I am in favor of killing the "module" type and converting everything to plugins, but this is a massive change which requires careful review and public discussion

          Oleg Nenashev added a comment - I think it needs a JEP. I am in favor of killing the "module" type and converting everything to plugins, but this is a massive change which requires careful review and public discussion

          Jesse Glick added a comment -

          It is actually not a large change at all; turned out to be quite straightforward. See the core PR for summary.

          Jesse Glick added a comment - It is actually not a large change at all; turned out to be quite straightforward. See the core PR for summary.

          Basil Crow added a comment -

          Or, alternatively, do none of this…?

          I think this is worth doing. Right now, it's more or less impossible for plugins to depend on modules in a sane way (see the discussion in jenkinsci/git-server-plugin#10 to see what I mean). With this change in place, plugins could explicitly depend on the correct version of the "module" (turned plugin) that they need.

          Basil Crow added a comment - Or, alternatively, do none of this…? I think this is worth doing. Right now, it's more or less impossible for plugins to depend on modules in a sane way (see the discussion in jenkinsci/git-server-plugin#10 to see what I mean). With this change in place, plugins could explicitly depend on the correct version of the "module" (turned plugin) that they need.

          Jesse Glick added a comment -

          I have a to-do item to write this up a JEP by the way.

          Jesse Glick added a comment - I have a to-do item to write this up a JEP by the way.

          Oleg Nenashev added a comment - - edited

          I have created WEBSITE-642 to deuglify the Plugin Site Web UI. Probably you want to convert this task to EPIC jglick

          Oleg Nenashev added a comment - - edited I have created WEBSITE-642 to deuglify the Plugin Site Web UI. Probably you want to convert this task to EPIC jglick

          Jesse Glick added a comment -

          Just now realized that the slave installers only work if the inbound agent is launched in “GUI” mode, which is only available when using javaws, which is semi-deprecated and might be dropped altogether if we decline to keep signing remoting.jar. (Anyway they are only useful if the user account launching the agent has administrator privileges to register a service.) So while slave-installer and its four implementations can still be trivially converted to plugins, we may decide to stop bundling them, meaning that we would be down to three detached plugins (instance-identity, ssh-cli-auth, sshd), which might ease some of the objections to this change.

          Jesse Glick added a comment - Just now realized that the slave installers only work if the inbound agent is launched in “GUI” mode, which is only available when using javaws , which is semi-deprecated and might be dropped altogether if we decline to keep signing remoting.jar . (Anyway they are only useful if the user account launching the agent has administrator privileges to register a service.) So while slave-installer and its four implementations can still be trivially converted to plugins, we may decide to stop bundling them, meaning that we would be down to three detached plugins ( instance-identity , ssh-cli-auth , sshd ), which might ease some of the objections to this change.

          jglickoleg_nenashev I recently started thinking to bump the Apache Mina to 2.5.x version on the SSHD module, doing it, I have found several works in progress related to this module, the bum of the library JENKINS-60902, and this one about converting the module in a plugin. After thinking deeply about it I think that we have to move it first to plugin and then bump the version of the library. So, If you do not have any objection, I'd like to take ownership of move SSHD module to a plugin, I have made one of those in the past wit the trilead-ssh2.

          Ivan Fernandez Calvo added a comment - jglick oleg_nenashev I recently started thinking to bump the Apache Mina to 2.5.x version on the SSHD module, doing it, I have found several works in progress related to this module, the bum of the library JENKINS-60902 , and this one about converting the module in a plugin. After thinking deeply about it I think that we have to move it first to plugin and then bump the version of the library. So, If you do not have any objection, I'd like to take ownership of move SSHD module to a plugin, I have made one of those in the past wit the trilead-ssh2.

          Jesse Glick added a comment - - edited

          I was actually thinking about resurrecting this effort and filing a JEP with the updated proposal. One change from the initial proposal would be to inline ssh-cli-auth into sshd. ifernandezcalvo Do you mind waiting a day or two for me to file a JEP draft so we have a baseline for discussion? It should be possible to separate the actual work and do it in stages, so it would be perfect if you wanted to handle the SSH-related portions, since you have the detailed knowledge of associated issues.

          Jesse Glick added a comment - - edited I was actually thinking about resurrecting this effort and filing a JEP with the updated proposal. One change from the initial proposal would be to inline ssh-cli-auth into sshd . ifernandezcalvo Do you mind waiting a day or two for me to file a JEP draft so we have a baseline for discussion? It should be possible to separate the actual work and do it in stages, so it would be perfect if you wanted to handle the SSH-related portions, since you have the detailed knowledge of associated issues.

          sure, there is no rush.

          Ivan Fernandez Calvo added a comment - sure, there is no rush.

          Jesse Glick added a comment -

          I filed jep #326 to both formalize this change and reflect changes to my original proposal.

          Jesse Glick added a comment - I filed jep #326 to both formalize this change and reflect changes to my original proposal.

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

              Created:
              Updated:
              Resolved: