Details

    • Type: New Feature
    • Status: Done (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Component/s: plugin-site
    • Labels:
      None
    • Similar Issues:

      Description

      There's a second class of dependencies to be aware of: Implied dependencies. Basically, some plugins used to be core features (e.g. Subversion, or JUnit plugin). Other plugins that have been developed against versions of core old enough that those features were in core may or may not be using these (formerly core) features – so Jenkins treats them as if they do. So an older core version dependency can therefore mean a plugin picks up a number of implied dependencies. We should also display these, but in a separate list next to the regular guaranteed-to-be-used dependencies we already show.

      This list maintained in code unfortunately, contains these "detached" (used to be in core and now are not) plugins, the version in which they were removed from core (i.e. 1.576 was the last core to contain junit features), and which version of the newly created plugin the implied dependency is on (usually 1.0 but not always)


      Addressing comments in WEBSITE-327: Showing the 'reverse dependencies' for these makes no sense, as some plugins may have 1000+ reverse dependencies.

        Attachments

          Issue Links

            Activity

            Hide
            mmccaskill Michael McCaskill added a comment -

            Are you saying:

            1. If one of these 15 plugins is shown (e.g. https://plugins.jenkins.io/mailer) then somewhere on the page we should indicate this is an implied dependency.
            2. if one of these 15 plugins is a dependency for a plugin it should be marked in separate list. e.g. https://plugins.jenkins.io/git has mailer as a dependency, so mailer should be in a different list.
            Show
            mmccaskill Michael McCaskill added a comment - Are you saying: If one of these 15 plugins is shown (e.g. https://plugins.jenkins.io/mailer ) then somewhere on the page we should indicate this is an implied dependency. if one of these 15 plugins is a dependency for a plugin it should be marked in separate list. e.g. https://plugins.jenkins.io/git has mailer as a dependency, so mailer should be in a different list.
            Hide
            danielbeck Daniel Beck added a comment - - edited

            Neither.

            Git has an explicit dependency on Mailer, that's why it shows up in the list. Git requires a core (1.625.3) from after Mailer was split off (1.493), so needs to declare an explicit dependency if it wants to integrate it.

            The idea is that any plugin requiring core 1.492 or older will have a dependency on Mailer added in a separate list, as these may or may not use the plugin functionality.

            So, example: https://plugins.jenkins.io/aws-codepipeline depends on core 1.479. This plugin has the following Implied Dependencies:

            • mailer 1.2
            • matrix-auth 1.0.2
            • windows-slaves 1.0
            • antisamy-markup-formatter 1.0
            • matrix-project 1.0
            • junit 1.0
            • bouncycastle-api 2.16.0
            Show
            danielbeck Daniel Beck added a comment - - edited Neither. Git has an explicit dependency on Mailer, that's why it shows up in the list. Git requires a core (1.625.3) from after Mailer was split off (1.493), so needs to declare an explicit dependency if it wants to integrate it. The idea is that any plugin requiring core 1.492 or older will have a dependency on Mailer added in a separate list, as these may or may not use the plugin functionality. So, example: https://plugins.jenkins.io/aws-codepipeline depends on core 1.479. This plugin has the following Implied Dependencies: mailer 1.2 matrix-auth 1.0.2 windows-slaves 1.0 antisamy-markup-formatter 1.0 matrix-project 1.0 junit 1.0 bouncycastle-api 2.16.0
            Hide
            mmccaskill Michael McCaskill added a comment -

            So basically if the plugin version is older than the splitWhen version it's implied based on your example above. So for example maven-plugin was split off 1.296 which is why it's not implied.

            Show
            mmccaskill Michael McCaskill added a comment - So basically if the plugin version is older than the splitWhen version it's implied based on your example above. So for example maven-plugin was split off 1.296 which is why it's not implied.
            Hide
            danielbeck Daniel Beck added a comment -

            Michael McCaskill Yes, but let me rephrase to make sure we're on the same page:

            If a plugin depends on a core older than the splitWhen version it has an implied dependency on the plugin split off from core.

            Show
            danielbeck Daniel Beck added a comment - Michael McCaskill Yes, but let me rephrase to make sure we're on the same page: If a plugin depends on a core older than the splitWhen version it has an implied dependency on the plugin split off from core.
            Hide
            mmccaskill Michael McCaskill added a comment -

            Yes I think we are now. Thanks.

            Show
            mmccaskill Michael McCaskill added a comment - Yes I think we are now. Thanks.
            Hide
            tom_gl Thomas de Grenier de Latour added a comment - - edited

            FWIW, some user feedback now that #44 has been merged... I find the current state of the plugins site, with implied deps being listed as "(required)", really confusing

            To give you some context, I'm in charge of many internal Jenkins instances in my company, which we provide to our users (dev teams) with a preset of bundled plugins. We take care of upgrading these instances, etc, and to keep things manageable we disable access to the update center, and only allow users to upload .hpi files for their very specific needs, provided that they take care of checking dependencies are satisfied.
            Yesterday, we've received a support request explaining that it was impossible to install the "ansible" plugin (by uploading the .hpi), because of its dependency on "command-launcher". This weird idea of a dependency from "ansible" to "command-launcher" was actually coming straight from the plugins site (https://plugins.jenkins.io/ansible). Of course the Jenkins instance was still 2.73.3 (whereas "command-lancher" has only be extracted from core in some 2.8x version and can't be installed on earlier version), and thus this user was actually unable to install "command-launcher", and was feeling stuck on this imaginary issue.

            So, yes, my point is that this change to the plugins site is confusing. At least for users who are forced to carefully refer to this list of dependencies because of some very non-standard way of doing the Jenkins in their company. OK, not a very strong point. But still, the info on the plugin page used to be slightly incomplete, and now it is incoherent (it doesn't make sense for a plugin to depend on both "core 1.596" and on "command-launcher", but that's how it looks like now for "ansible"), which I don't think is any better.

            Hence I'd like to humbly suggest you revert this change, until you also implement a specific display for these dependencies (ie mark them as "(implied)", or even better "(implied for Jenkins >= x.yy)"). Thanks for reading...

            Show
            tom_gl Thomas de Grenier de Latour added a comment - - edited FWIW, some user feedback now that  #44 has been merged... I find the current state of the plugins site, with implied deps being listed as "(required)", really confusing To give you some context, I'm in charge of many internal Jenkins instances in my company, which we provide to our users (dev teams) with a preset of bundled plugins. We take care of upgrading these instances, etc, and to keep things manageable we disable access to the update center, and only allow users to upload .hpi files for their very specific needs, provided that they take care of checking dependencies are satisfied. Yesterday, we've received a support request explaining that it was impossible to install the "ansible" plugin (by uploading the .hpi), because of its dependency on "command-launcher". This weird idea of a dependency from "ansible" to "command-launcher" was actually coming straight from the plugins site ( https://plugins.jenkins.io/ansible ). Of course the Jenkins instance was still 2.73.3 (whereas "command-lancher" has only be extracted from core in some 2.8x version and can't be installed on earlier version), and thus this user was actually unable to install "command-launcher", and was feeling stuck on this imaginary issue. So, yes, my point is that this change to the plugins site is confusing. At least for users who are forced to carefully refer to this list of dependencies because of some very non-standard way of doing the Jenkins in their company. OK, not a very strong point. But still, the info on the plugin page used to be slightly incomplete, and now it is incoherent (it doesn't make sense for a plugin to depend on both "core 1.596" and on "command-launcher", but that's how it looks like now for "ansible"), which I don't think is any better. Hence I'd like to humbly suggest you revert this change, until you also implement a specific display for these dependencies (ie mark them as "(implied)", or even better "(implied for Jenkins >= x.yy)"). Thanks for reading...
            Hide
            danielbeck Daniel Beck added a comment -

            implement a specific display for these dependencies

            Still on the todo list, probably in the next week or two.

            Show
            danielbeck Daniel Beck added a comment - implement a specific display for these dependencies Still on the todo list, probably in the next week or two.

              People

              • Assignee:
                danielbeck Daniel Beck
                Reporter:
                danielbeck Daniel Beck
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: