It would be useful to include support for Git in the standard jenkins distribution.

      As a new Jenkins user, I will like to choose a feature area that I am interested in and Jenkins installs the related plugins for me.
      As an existing Jenkins user who is upgrading, I will like to choose the feature areas that I am interested in and Jenkins installs the related plugins for me.

          [JENKINS-9598] Overhaul bundled plugins or setup experience

          John Smart created issue -

          +1

          Conny Kreyßel added a comment - +1

          Tim Pizey added a comment -

          +1

          Tim Pizey added a comment - +1

          The interest is just to not have to install it by default ?
          Is it really relevant ?
          Are you really using Jenkins out of the box without any additional plugin ?
          I would prefer that we study the ability to prepare some sets of plugins (by technology, by compatibility with the core ...) that users could install to have a ready to go environment for a given profile of usage.
          WDYT ?

          Arnaud Héritier added a comment - The interest is just to not have to install it by default ? Is it really relevant ? Are you really using Jenkins out of the box without any additional plugin ? I would prefer that we study the ability to prepare some sets of plugins (by technology, by compatibility with the core ...) that users could install to have a ready to go environment for a given profile of usage. WDYT ?

          John Smart added a comment -

          The idea is to get users up and running as quickly as possible. (The other idea is so that readers of the 'First Steps' chapter in 'Jenkins: The Definitive Guide' can get a few builds running with a minimum of configuration ).

          Seriously, though, I'd even be prone to bundle recent versions of Maven (e.g. 2.2.1 and 3.0.x) and Ant for the same reasons. Beyond that, the idea of themed plugin sets does sound quite cool.

          John Smart added a comment - The idea is to get users up and running as quickly as possible. (The other idea is so that readers of the 'First Steps' chapter in 'Jenkins: The Definitive Guide' can get a few builds running with a minimum of configuration ). Seriously, though, I'd even be prone to bundle recent versions of Maven (e.g. 2.2.1 and 3.0.x) and Ant for the same reasons. Beyond that, the idea of themed plugin sets does sound quite cool.

          @aheretier
          Is its relevant to have SVN/CVS plugin in distribution? Today, i think git is relevant.

          Conny Kreyßel added a comment - @aheretier Is its relevant to have SVN/CVS plugin in distribution? Today, i think git is relevant.

          davidmc24 added a comment -

          Bundling plugins will always result in increasing the size of the distribution to make life easier for some people (eliminating the need to manually install a plugin they want) while adding bloat for others (adding the need to either ignore or manually disable a plugin they don't want). I'd rather have the official Jenkins distribution come with as few plugins as possible (possibly eventually even not bundling the SVN/CVS/Maven plugins).

          For most users, I think they'll be better served by learning how to use the Plugin Manager to install plugins, as they'll likely also want to use it to install other plugins and update plugins.

          For some users, it might be useful to have a concept of a plugin profile, which allows specifying a set of plugins to install if not already present (either the "latest available" version or a specified version). This might serve as a lighter-weight alternative to some use cases for bundling plugins into a custom jenkins.war. This could allow creation of standard plugin profiles for common configurations.

          https://wiki.jenkins-ci.org/display/JENKINS/Bundling+plugins+with+Jenkins

          davidmc24 added a comment - Bundling plugins will always result in increasing the size of the distribution to make life easier for some people (eliminating the need to manually install a plugin they want) while adding bloat for others (adding the need to either ignore or manually disable a plugin they don't want). I'd rather have the official Jenkins distribution come with as few plugins as possible (possibly eventually even not bundling the SVN/CVS/Maven plugins). For most users, I think they'll be better served by learning how to use the Plugin Manager to install plugins, as they'll likely also want to use it to install other plugins and update plugins. For some users, it might be useful to have a concept of a plugin profile, which allows specifying a set of plugins to install if not already present (either the "latest available" version or a specified version). This might serve as a lighter-weight alternative to some use cases for bundling plugins into a custom jenkins.war . This could allow creation of standard plugin profiles for common configurations. https://wiki.jenkins-ci.org/display/JENKINS/Bundling+plugins+with+Jenkins

          mattyt added a comment -

          -1

          I'd strongly prefer to have Jenkins as lightweight as possible out of the box.

          Even removing SVN/CVS would be preferable for me - I use both Git and SVN (and Mercurial) but not both on all of my Jenkins installs. Maven and Ant? None of my Jenkins installs uses either tool and I'd prefer they weren't installed by default.

          I agree that better management of 'bundles' of plugins would be useful but, as davidmc24 pointed out, there is a solution for this...

          mattyt added a comment - -1 I'd strongly prefer to have Jenkins as lightweight as possible out of the box. Even removing SVN/CVS would be preferable for me - I use both Git and SVN (and Mercurial) but not both on all of my Jenkins installs. Maven and Ant? None of my Jenkins installs uses either tool and I'd prefer they weren't installed by default. I agree that better management of 'bundles' of plugins would be useful but, as davidmc24 pointed out, there is a solution for this...

          Andrew Gray added a comment -

          Reading through all of the preceding comments the positions taken appear to view this as an either/or scenario.

          EITHER
          A heavier download with more plugins included to get going faster (valid if that is where your knowledge levels are)
          OR
          A lightweight download that is quicker to download so plugins can be mixed and matched and kept "tight" for your specific needs.

          I suggest this does not have to be an either/or situation?

          Here is another idea:
          We already have platform specific distributions (Windows, Ubuntu/Debian, RedHat etc). Why not have a number of other distributions that include different sets of plugins.
          These new distros should be IN ADDITION to the current available distros. The current distros should be as light as possible thus serving the demographic that don't want bloated Jenkins.

          I see a download page that asks the user a series of questions (answers provided via dropdown lists) about how they want to use Jenkins.
          Eg: What Source Control System do you wish Jenkins to use?, Do you have testing code? If so, what kind is it? What analysis do you wish Jenkins to perform on your code?, How do you wish to notify people of results?

          The combination of answers would drive which sets of plugins get included in the distribution.

          This would provide a starting point for the newbie user and should still be able to visit the update center to further customise/change their Jenkins as their knowledge increases.

          I think this would be a major improvement and give people another way to access Jenkins.

          What do people think of this proposal?

          Cheers,

          Andrew

          Andrew Gray added a comment - Reading through all of the preceding comments the positions taken appear to view this as an either/or scenario. EITHER A heavier download with more plugins included to get going faster (valid if that is where your knowledge levels are) OR A lightweight download that is quicker to download so plugins can be mixed and matched and kept "tight" for your specific needs. I suggest this does not have to be an either/or situation? Here is another idea: We already have platform specific distributions (Windows, Ubuntu/Debian, RedHat etc). Why not have a number of other distributions that include different sets of plugins. These new distros should be IN ADDITION to the current available distros. The current distros should be as light as possible thus serving the demographic that don't want bloated Jenkins. I see a download page that asks the user a series of questions (answers provided via dropdown lists) about how they want to use Jenkins. Eg: What Source Control System do you wish Jenkins to use?, Do you have testing code? If so, what kind is it? What analysis do you wish Jenkins to perform on your code?, How do you wish to notify people of results? The combination of answers would drive which sets of plugins get included in the distribution. This would provide a starting point for the newbie user and should still be able to visit the update center to further customise/change their Jenkins as their knowledge increases. I think this would be a major improvement and give people another way to access Jenkins. What do people think of this proposal? Cheers, Andrew

          davidmc24 added a comment -

          With regard to apgray's proposal, I'm still not seeing the need for a different mechanism for installing plugins (even just initially) than the one we already have: the Plugin Manager.

          If it's too hard to figure out that you should use the Plugin Manager to install plugins, we should improve the navigation or provide hints to the user to ease that learning curve.

          If it's too hard to find the plugins you want to install in the Plugin Manager we should address that, possibly by changing the categorization, introducing a rating or popularity system, or even adding an initial wizard to guide them through selection of the most common plugins.

          What we shouldn't do is introduce a redundant way to install plugins which has the side-effect of eliminating/reducing the need for users to know about the Plugin Manager. If a newbie user does their initial install via the proposed questionare-based custom bundle builder, they may well think that that's just the way that plugins are managed in Jenkins. When they next need a plugin, they may go back to that wizard, and try to answer the questions in a way to get it (and likely fail, since the questionare would be way too complicated if it covered all possible plugins), thinking that the plugins available through the bundle builder are all there are.

          The vibrant plugin community is one of the things that makes Jenkins great. Let's not shoot ourselves in the feet by hiding it from the users.

          davidmc24 added a comment - With regard to apgray's proposal, I'm still not seeing the need for a different mechanism for installing plugins (even just initially) than the one we already have: the Plugin Manager. If it's too hard to figure out that you should use the Plugin Manager to install plugins, we should improve the navigation or provide hints to the user to ease that learning curve. If it's too hard to find the plugins you want to install in the Plugin Manager we should address that, possibly by changing the categorization, introducing a rating or popularity system, or even adding an initial wizard to guide them through selection of the most common plugins. What we shouldn't do is introduce a redundant way to install plugins which has the side-effect of eliminating/reducing the need for users to know about the Plugin Manager. If a newbie user does their initial install via the proposed questionare-based custom bundle builder, they may well think that that's just the way that plugins are managed in Jenkins. When they next need a plugin, they may go back to that wizard, and try to answer the questions in a way to get it (and likely fail, since the questionare would be way too complicated if it covered all possible plugins), thinking that the plugins available through the bundle builder are all there are. The vibrant plugin community is one of the things that makes Jenkins great. Let's not shoot ourselves in the feet by hiding it from the users.

            Unassigned Unassigned
            wakaleo John Smart
            Votes:
            24 Vote for this issue
            Watchers:
            20 Start watching this issue

              Created:
              Updated:
              Resolved: