Re: Revisiting bundled plugins

I started a new thread specific to the Plugin Install Wizard. See here . -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop

Re: Revisiting bundled plugins

Ok, thanks guys. We can park the "plugins in core" discussion and have that in a separate thread. As far as the install wizard is concerned, lets say it will be totally self contained and will be loaded conditionally. -- You received this message because you are subscribed to the Google Groups

Re: Revisiting bundled plugins

Sorry ... typo in #2 on the last email. I should have said "This only seems relevant to me if the answer to #1 is no" i.e. we will upgrade if the plugin does not meet the minimum version requirements i.e. is less than the bundled version (in /WEB-INF/detached-plugins). On 17 September 2015 at

Re: Revisiting bundled plugins

On 17.09.2015, at 11:26, Tom Fennelly wrote: > Sorry ... typo in #2 on the last email. I should have said "This only seems > relevant to me if the answer to #1 is no" i.e. we will upgrade if the plugin > does not meet the minimum version requirements i.e. is less than

Re: Revisiting bundled plugins

On 17.09.2015, at 13:02, Tom Fennelly wrote: > while other plugins are just "dependency" plugins … and are dependencies … > Jenkins core itself. These do not exist today. If you need them for other changes, this will need to be considered separately. Remember, every

Re: Revisiting bundled plugins

So where are we now guys? 1. Are we still saying we are not going to update existing plugins on an upgrade? Jesse seemed definitive on this one but I still don't know the reasoning. 2. Are we still saying pinned files should be ignored ala what Jesse said earlier? Again, I still

Re: Revisiting bundled plugins

Maybe we should clarify what it means for a plugin to be bundled in "/WEB-INF/plugins" Vs "/WEB-INF/detached-plugins". My understanding/interpretation is: - */WEB-INF/plugins*: These are plugins that must always be installed/updated. Same as before. The versions are kept as up-to-date as

Re: Revisiting bundled plugins

On Thu, Sep 17, 2015 at 11:49 AM, Tom Fennelly wrote: >> Jenkins core cannot depend on a plugin, this makes no sense. > > I still don't get why it's such a no-no. Violates the very notion of what a “plugin” is. By definition, plugins depend on core, and core does not

Re: Revisiting bundled plugins

On Thursday, September 17, 2015 at 1:04:15 PM UTC+1, Daniel Beck wrote: > > > On 17.09.2015, at 13:02, Tom Fennelly > wrote: > > > while other plugins are just "dependency" plugins … and are dependencies > … Jenkins core itself. > > These do not exist today. Sure, I'm

Re: Revisiting bundled plugins

On Thu, Sep 17, 2015 at 6:16 AM, Daniel Beck wrote: >> we will upgrade if the plugin does not meet the minimum version requirements >> i.e. is less than the bundled version (in /WEB-INF/detached-plugins). > > Yep, it looks like that's what Jesse is arguing for. Yes. So my

Re: Revisiting bundled plugins

I second the idea that core should not depend on a plugin. This seems it would lead to lots of compatibility issues. Core should be self contained. On Thu, Sep 17, 2015, 09:53 Tom Fennelly wrote: > On Thursday, September 17, 2015 at 5:38:37 PM UTC+1, Jesse Glick wrote: >

Re: Revisiting bundled plugins

On Thursday, September 17, 2015 at 5:38:37 PM UTC+1, Jesse Glick wrote: > > On Thu, Sep 17, 2015 at 11:49 AM, Tom Fennelly > wrote: > >> Jenkins core cannot depend on a plugin, this makes no sense. > > > > I still don't get why it's such a no-no. > > Violates the very

Re: Revisiting bundled plugins

It would be good if some people could try out what we've done so far and let is know. Here's a link to a jenkins.war from the PR Builder (or get the latest build via the PR

Re: Revisiting bundled plugins

On Wed, Sep 16, 2015 at 3:42 AM, Tom Fennelly wrote: > The plugin in WEB-INF/detached-plugins is already already installed in > "this" jenkins instance. > The only effect here will be a possible upgrade of the plugin if the > installed version is less than the bundled

Re: Revisiting bundled plugins

On Wednesday, September 16, 2015 at 2:50:31 PM UTC+1, Jesse Glick wrote: > > On Wed, Sep 16, 2015 at 3:42 AM, Tom Fennelly > wrote: > > The plugin in WEB-INF/detached-plugins is already already installed in > > "this" jenkins instance. > > The only effect here will be a

Re: Revisiting bundled plugins

I also hate "pinned". WtF does it mean? I now know, but it is sorta crazy. If we have to keep it, we have to keep it, but it does suck. On Wed, Sep 16, 2015 at 9:09 AM, Tom Fennelly wrote: > On Wednesday, September 16, 2015 at 2:50:31 PM UTC+1, Jesse Glick wrote: >> >>

Re: Revisiting bundled plugins

> I see. Basically this is what `PinningIsBlockingBundledPluginMonitor` > was designed to help with, though it sounds like you are getting some > error earlier and more intrusively than that was designed to handle. > Can we treat this particular error as a robustness bug? It's not a notable

Re: Revisiting bundled plugins

On Wed, Sep 16, 2015 at 1:33 PM, Daniel Beck wrote: > The issue that caused me to think we may need to keep pinning around is your > change to External Monitor Job 1.4 where a resource was moved from core into > the plugin. I see. Basically this is what

Re: Revisiting bundled plugins

On Wed, Sep 16, 2015 at 3:49 PM, Daniel Beck wrote: > Worst case is we'll need to backport the critical fix to an older x.y.1 so we > don't include a bunch of unrelated stuff. Exactly. -- You received this message because you are subscribed to the Google Groups "Jenkins

Re: Revisiting bundled plugins

On 16.09.2015, at 15:50, Jesse Glick wrote: > On Wed, Sep 16, 2015 at 3:42 AM, Tom Fennelly wrote: >> The plugin in WEB-INF/detached-plugins is already already installed in >> "this" jenkins instance. >> The only effect here will be a possible

Re: Revisiting bundled plugins

A WiP PR relating to this: https://github.com/jenkinsci/jenkins/pull/1822 -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: Revisiting bundled plugins

On Friday, September 4, 2015 at 3:31:54 PM UTC+1, James Nord wrote: > > For v1 all I am saying is we need to have *a* solution to the problem > (not *what* that solution needs to be). If the chosen solution is > pointing users to a document that explains some workarounds (possibly > provides

Re: Revisiting bundled plugins

On Friday, September 4, 2015 at 5:37:26 PM UTC+1, Daniel Beck wrote: > > >> For version 1 of this, can't we just document some possible solutions > to this problem and point the user to these solutions from inside the > wizard on detecting the fact that there's no internet connection? This >

Re: Revisiting bundled plugins

+1 Tom. That's common sense, It's always useful :) That percentage of people who try to install Jenkins offline, use to know what they are doing, so a link to "Tips to install Jenkins offline" should be enough. On Wed, Sep 2, 2015 at 10:57 PM, Tom Fennelly wrote: > On 2

Re: Revisiting bundled plugins

I have worked in the past on software for facilities that were truly offline (military, literal ships in the navy etc) and they have a lot of their own techniques for bundling software as even off the shelf things that claim to work offline dont. For a class of advanced user I don't think this

Re: Revisiting bundled plugins

On Wednesday, September 2, 2015 at 8:17:44 PM UTC+1, Stephen Connolly wrote: > > I think one thing that people don't quite grasp is how annoying the > current bundling mechanism is: > > * once there is a .pinned file then the plugin will never be overwritten > by the bundled one. > > That was

Re: Revisiting bundled plugins

> On 04.09.2015, at 07:31, James Nord wrote: > >> • What percentage of Jenkins install locations do you expect have no >> internet connection? > > I don't know - we don't collect statistics from those types of machines :-/ We might, as the usage stats are sent by

Re: Revisiting bundled plugins

For me, the issue is *forced* bundling. If we switch to optional bundling with a wizard to allow selection that seems less evil. Though the risk them becomes everyone and their mother wanting another plugin in the optionally bundled set and before long Jenkins.war comes with 1100+ plugins

Re: Revisiting bundled plugins

I think one thing that people don't quite grasp is how annoying the current bundling mechanism is: * if a plugin is bundled, it will be installed automatically. * you can disable it manually, so it can be "uninstalled" but it will still be in the JENKINS_HOME/plugins directory and show in the

Re: Revisiting bundled plugins

On 2 September 2015 at 15:04, James Nord wrote: > Lets get something working and then see how we can evolve it to fill gaps. >> > > Well I can see the headlines now if you release with that in mind > "Jenkins, marketed as the leading CI/CD software, no longer supports >

Re: Revisiting bundled plugins

> > So James, are you then arguing that we should leave the existing plugin > bundle alone? Hell no :) ...or are you just saying a remote connection for initial plugin collecting > is problematic? > This *could *be problematic for a certain type of users who are not experienced jenkins

Re: Revisiting bundled plugins

> > Lets get something working and then see how we can evolve it to fill gaps. > Well I can see the headlines now if you release with that in mind "Jenkins, marketed as the leading CI/CD software, no longer supports JUnit the tool used in 99.9% of all development" out of the box <- cos

Re: Revisiting bundled plugins

Yes the unbundling if things sounds doors sound like a painful idea, but that brings us back to the problem of a consensus of what is bundled. On Wed, 2 Sep 2015 at 7:04 am James Nord wrote: > Lets get something working and then see how we can evolve it to fill gaps. >> > >

Re: Revisiting bundled plugins

On Tuesday, September 1, 2015, Jesse Glick wrote: > On Tue, Sep 1, 2015 at 12:30 PM, James Nord > wrote: > > Eclipse.org > > provides "distributions" you can get the basic IDE and add the plugins > you > > want - or you can get the Java

Re: Revisiting bundled plugins

I agree, I always dreaded going to eclipse.org and worrying I have just downloaded 300Meg of the wrong thing. On Tue, Sep 1, 2015 at 1:30 PM Baptiste Mathus wrote: > 2015-09-01 20:08 GMT+02:00 Jesse Glick : > >> On Tue, Sep 1, 2015 at 12:30 PM, James Nord

Re: Revisiting bundled plugins

2015-09-01 20:08 GMT+02:00 Jesse Glick : > On Tue, Sep 1, 2015 at 12:30 PM, James Nord wrote: > > Eclipse.org > > provides "distributions" you can get the basic IDE and add the plugins > you > > want - or you can get the Java version, or the J2EE

Re: Revisiting bundled plugins

It's been a while since I installed eclipse simply because I hated it and moved away from it. My experience of the litany of download options was the same as Mic's i.e. pissed off after wasting 30 mins waiting on the wrong download to complete. I think we could engineer multiple options for this

Re: Revisiting bundled plugins

> On 01.09.2015, at 13:23, Michael Neale wrote: > > He also brought up the eclipse.org style "distributions" or "flavors" which I > am sure has been brought up before (I can't recall objections though) Variants make life extremely difficult. Remember each release

Re: Revisiting bundled plugins

Daniel, So while these are all relevant points, it's a completely different issue, > only affecting very experienced users in an unusually restrictive > environment only. Everyone else just uses the update center. > You responded to this when it was explicitly about restrictive environments.

Re: Revisiting bundled plugins

On 29.08.2015, at 10:46, James Nord wrote: > That should work, but I don't see how that would work with mirroring. I > would rather see something generate a zip containing the plugins and deps > being generated that you can upload in one rather than generating new wars,

Re: Revisiting bundled plugins

On 29.08.2015, at 01:42, James Nord wrote: > Yeah of you forget about tracking down the dependencies and downloading those > one by one and making sure you get the version compatible with the version of > Jenkins you want to run rather than the latest. And you expect

Re: Revisiting bundled plugins

That should work, but I don't see how that would work with mirroring. I would rather see something generate a zip containing the plugins and deps being generated that you can upload in one rather than generating new wars, otherwise the poor people that use the native packages will be out in

Re: Revisiting bundled plugins

+1 On Thu, Aug 27, 2015 at 5:37 PM, Gus Reiber grei...@cloudbees.com wrote: Hey all, So with the dust settled here a bit, I am hoping to solidify some points of agreement: 1) Jenkins plugin bundling has some issues. Not only is the list of what gets installed no longer optimal, it

Re: Revisiting bundled plugins

Yeah of you forget about tracking down the dependencies and downloading those one by one and making sure you get the version compatible with the version of Jenkins you want to run rather than the latest. And you expect new users to do that?! -- You received this message because you are

Re: Revisiting bundled plugins

Wouldn't it be possible to have a war customizer that runs on the website to download a custom war with the plugins you want/need with dependency resolution? I remember some site doing this for eclipse some time ago and it worked very well. On Fri, Aug 28, 2015 at 4:42 PM James Nord

Re: Revisiting bundled plugins

That's why at the very beginning of the thread I added: And if it is for next Xmas: Don't forget all users who are deploying Jenkins in a environment with no internet (or a limited access). Thus if we could pack together some set of plugins (and required dependencies) and allow jenkins to eat

Re: Revisiting bundled plugins

I didn't know this one. I will give it a try. Maybe a thing to better promote. On Thu, Aug 27, 2015 at 3:21 PM, Daniel Beck m...@beckweb.net wrote: On 27.08.2015, at 15:19, Arnaud Héritier aherit...@gmail.com wrote: Deploying plugins one by one is a nightmare and error prone It takes

Re: Revisiting bundled plugins

2015-08-23 9:42 GMT-04:00 Kanstantsin Shautsou kanstantsin@gmail.com: This topic was also rejected by governance meeting. Nit picking, but factual clarification. The proposal wasn't rejected. I retracted it based on the feedback. -- Kohsuke Kawaguchi -- You received this message

Re: Revisiting bundled plugins

On 27.08.2015, at 15:19, Arnaud Héritier aherit...@gmail.com wrote: Deploying plugins one by one is a nightmare and error prone It takes about ten minutes to make your folder of blessed plugin HPIs into an update site. https://jenkins-ci.org/content/juseppe-custom-update-site-jenkins Skip

Re: Revisiting bundled plugins

On Thu, Aug 27, 2015 at 11:37 AM, Gus Reiber grei...@cloudbees.com wrote: detached plugins that are essential to Jenkins but have been implemented as plugins for quicker updates and ease of implementation. Split plugins are just plugins, which by definition are not “essential” to Jenkins. They

Re: Revisiting bundled plugins

After discussion with Tom and Gus I changed parts of the chapter The Jenkins Distribution (jenkins.war) that were referring to essential plugins, as none of the plugins are required for Jenkins to properly work -- they just extend its functionality. Jesse (and everyone who read the first

Re: Revisiting bundled plugins

Fair enough. Daniel is offering the same concerns and it seems the doc isn't clear enough on exactly how we intend to do away with the notion of essential plugins and completely unwind the current notion of bundled plugins. Fixing exactly what we don't like about bundled plugins will be the

Re: Revisiting bundled plugins

Hey all, So with the dust settled here a bit, I am hoping to solidify some points of agreement: 1) Jenkins plugin bundling has some issues. Not only is the list of what gets installed no longer optimal, it contains a mix of feature plugins that sometimes are nice, but aren't essential to

Re: install CD (Was RE: Revisiting bundled plugins)

...@googlegroups.com javascript: Subject: Re: Revisiting bundled plugins On Sun, Aug 23, 2015 at 2:47 PM, Sacha Labourey sa...@cloudbees.com javascript: wrote: This setup makes the (high) availability (and bandwidth capacity) of the update center (the setup center in that scenario) a key

Re: Revisiting bundled plugins

On Sun, Aug 23, 2015 at 2:47 PM, Sacha Labourey sa...@cloudbees.com wrote: This setup makes the (high) availability (and bandwidth capacity) of the update center (the setup center in that scenario) a key requirement (center down = no install of Jenkins is possible anymore).

RE: install CD (Was RE: Revisiting bundled plugins)

, 2015 11:41 AM To: Jenkins Dev jenkinsci-dev@googlegroups.com Subject: Re: Revisiting bundled plugins On Sun, Aug 23, 2015 at 2:47 PM, Sacha Labourey sa...@cloudbees.com wrote: This setup makes the (high) availability (and bandwidth capacity) of the update center (the setup center

Re: Revisiting bundled plugins

+1 on removing those and +1 on at least adding git (I can't imagine a world without git - may just be me?). FWIW, for many people the size isn't as much as an issue as it once was. Look at the success of docker (even the official jenkins docker image gets a good lot of downloads), for the

Re: Revisiting bundled plugins

Thanks for the feedback Daniel. This setup makes the (high) availability (and bandwidth capacity) of the update center (the setup center in that scenario) a key requirement (center down = no install of Jenkins is possible anymore). Cheers, sacha On Sun, Aug 23, 2015 at 8:39 PM, Daniel Beck

Re: Revisiting bundled plugins

As I look over this thread, there does seem to be consensus that if we were to change the Jenkins plugin bundle at all, we would want to effectively remove them all from being installed. We would want to empty that set of bundled plugins not just because the distribution download size might get

Re: Revisiting bundled plugins

On 23.08.2015, at 11:44, Sacha Labourey sa...@cloudbees.com wrote: I understand this, but it forces new users to make a choice, when they are likely not equipped to make a choice. So we are forcing a first download, a choice, followed by another download (based on the choice she made), and

Re: Revisiting bundled plugins

Hello Daniel, On Sun, Aug 23, 2015 at 12:44 AM, Daniel Beck m...@beckweb.net wrote: On 22.08.2015, at 15:40, Sacha Labourey sa...@cloudbees.com wrote: My perception from this discussion is that we are aiming for the exact opposite i.e. slick and virgin for everybody and hope new users will

Re: Revisiting bundled plugins

When you are installing any linux distro, you has ability to choose software and it also requires restart. Gradle also has no default plugins enabled. If you want suggest somebody the number of plugins that is good by default for you, then make docker image and share (how Stephen proposed). You

Re: Revisiting bundled plugins

While I understand the engineering-idealism of a micro-kernel type architecture with dynamically loaded plugins where we end up packaging nothing outside of the kernel, the danger with that view is one of user experience. This view that since everybody is different, we might as well only provide

Re: Revisiting bundled plugins

On 22.08.2015, at 15:40, Sacha Labourey sa...@cloudbees.com wrote: My perception from this discussion is that we are aiming for the exact opposite i.e. slick and virgin for everybody and hope new users will be able to magically decide what a good average getting started experience might be,

Re: Revisiting bundled plugins

If I am following all this correctly, we have general agreement that Jenkins should stop bundling plugins all together, yeah? ...but some technical ifs and buts about upgrading (Jesse, Stephen, KK, and Tom can solve, but should not use pinning to do so)? Then to the extent we do want people to

Re: Revisiting bundled plugins

Gus Reiber is going to draw some screens for what a Plugin Selection Wizard might look like, allowing us to have a conversation about that. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving

Re: Revisiting bundled plugins

On Wednesday, August 19, 2015 at 1:55:58 PM UTC+1, Jesse Glick wrote: I thought I already proposed everything that was needed here. You did for sure. Sorry about that. I should not post late at night. The caveat: you actually know the last version in which global configuration was saved

Re: Revisiting bundled plugins

On Tue, Aug 18, 2015 at 5:01 PM, Tom Fennelly tom.fenne...@gmail.com wrote: could we use a simple plugin that needs to be installed that captures and records all split plugin info from the instance. This info can then be used on the subsequent install so as to install the exact versions of

Re: Revisiting bundled plugins

On Wed, Aug 19, 2015 at 9:52 AM, Tom Fennelly tom.fenne...@gmail.com wrote: I should not post late at night. I have been guilty of quite rude late-night posts. :-) The caveat: you actually know the last version in which global configuration was saved (if 1.301+), which is probably close to

Re: Revisiting bundled plugins

The procedure of core deciding when and what split plugins to install looks good. My take on Jenkins.version field is bit different that I think there will be a lot of people who haven't touched the system config for quite some time, which means it cannot be used as a reliable indication of what

Re: Revisiting bundled plugins

I don't have a solution for this, but to be honest, I think this is just way to complicated and just screams for issues in the long run. We should go for less magic and more transparency - I think we should just inform the users about this changes and not try to heal the world. We can also

Re: Revisiting bundled plugins

Hi Domi. When you say I don't have a solution for this, I think you are referring specifically to the issues around upgrades and split plugins, right? Wrt split plugins, I think the problem for a user doing an upgrade would be that they might not know exactly which split plugins they now need

Re: Revisiting bundled plugins

On Tuesday, August 18, 2015 at 10:01:28 PM UTC+1, Tom Fennelly wrote: Something I was wondering in order to help with upgrades ... could we use a simple plugin that needs to be installed that captures and records all split plugin info from the instance. This info can then be used on the

Re: Revisiting bundled plugins

Something I was wondering in order to help with upgrades ... could we use a simple plugin that needs to be installed that captures and records all split plugin info from the instance. This info can then be used on the subsequent install so as to install the exact versions of split plugins. An

Re: Revisiting bundled plugins

On Monday, August 17, 2015 at 9:11:25 PM UTC+1, Jesse Glick wrote: On Fri, Aug 14, 2015 at 5:51 PM, Kohsuke Kawaguchi k...@kohsuke.org javascript: wrote: when a plugin is split from core in version X, people upgrading from a version earlier will experiene functionality loss. Well I

Re: Revisiting bundled plugins

On Fri, Aug 14, 2015 at 5:51 PM, Kohsuke Kawaguchi k...@kohsuke.org wrote: when a plugin is split from core in version X, people upgrading from a version earlier will experiene functionality loss. Well I think this is what we should be spending a little effort fixing. IMO there be *no* bundled

Re: Revisiting bundled plugins

On Fri, Aug 14, 2015 at 6:20 PM, Kohsuke Kawaguchi k...@kohsuke.org wrote: when you type git in [the plugin manager] there are 30+ plugins that show up. It has already been proposed that we introduce an API for adding columns to Plugin Manager. This should be pretty easy. Then we can add a

Re: Revisiting bundled plugins

On 17 August 2015 at 21:11, Jesse Glick jgl...@cloudbees.com wrote: On Fri, Aug 14, 2015 at 5:51 PM, Kohsuke Kawaguchi k...@kohsuke.org wrote: when a plugin is split from core in version X, people upgrading from a version earlier will experiene functionality loss. Well I think this is what

Re: Revisiting bundled plugins

As an OSS contributor, I'm *-1* for any new bundled plugins excepting the decoupling from the Jenkins core. суббота, 15 августа 2015 г., 4:29:38 UTC+3 пользователь Kanstantsin Shautsou написал: From first days when i started using jenkins this bundled plugins were a pain. Also all

Re: Revisiting bundled plugins

in any way from its use. -- From: aherit...@gmail.com Date: Wed, 5 Aug 2015 22:53:33 +0200 Subject: Re: Revisiting bundled plugins To: jenkinsci-dev@googlegroups.com And if it is for next Xmas: Don't forget all users who are deploying Jenkins in a environment

Re: Revisiting bundled plugins

The wizard that you describe is quite in line with what's discussed in JENKINS-9598. However, note that at this time I'm specifically limiting the scope of the request to make a tactical shuffling of bundled plugins. 2015-08-05 13:51 GMT-07:00 Arnaud Héritier aherit...@gmail.com: O and I

Re: Revisiting bundled plugins

: Revisiting bundled plugins To: jenkinsci-dev@googlegroups.com And if it is for next Xmas: Don't forget all users who are deploying Jenkins in a environment with no internet (or a limited access). Thus if we could pack together some set of plugins (and required dependencies) and allow jenkins

Re: Revisiting bundled plugins

Thanks for all the comments. I started responding to comments one by one, but I think it's just going to end up dilluting the conversation, so instead let me explain where I am coming from for one more time, in the hope that it will frame the discussion in the way I want. A number of you have

Re: Revisiting bundled plugins

2015-08-07 0:12 GMT-07:00 Vincent Latombe vincent.lato...@gmail.com: +1. While you are at it, get rid of external-monitor-job which I think few people use. You could add windows-slaves to this list. external-monitor-job was split off from core in 1.467 and windows-slaves is 1.547. Those

Re: Revisiting bundled plugins

From first days when i started using jenkins this bundled plugins were a pain. Also all bundled plugins has irrelevant statistics, atm job dsl and build flow plugins has more installations rather than workflow. After you bundle it nobody will see a clear situation. Git plugin also has many

Re: Revisiting bundled plugins

I would love to see bundled/pinned plugins to go away and removing some bundled plugins without introducing new ones sounds like a good plan to me. What I would like to see implemented eventually is a support for custom plugin collections: Simple list of plugins (with minimal versions,

Re: Revisiting bundled plugins

I agree with Jesse, bundling new plugins is just pushing back the problem. What we really need is a better first time experience and I think Arnaud's wizard proposal makes sense. 2015-08-06 22:34 GMT+02:00 Jesse Glick jgl...@cloudbees.com: On Wed, Aug 5, 2015 at 1:56 AM, Kohsuke Kawaguchi

Re: Revisiting bundled plugins

I work in an industry which is inherently conservative about adding new stuff into their environments. So, I honestly think that this question might not affect only newcomers. Since we started using Jenkins we have set up our own plugin hub for internal plugins (with backend-update-center)

Re: Revisiting bundled plugins

I agree that adding bundled plugins just makes life more complex. In my view Jenkins would come bare bones empty... BUT you could upload a zip of plugins and Jenkins would install all required dependencies from that zip. That way, if I am in an isolated network I just need the zip and the war to

Re: Revisiting bundled plugins

+1 - sounds a great idea to me On Sat, 8 Aug 2015 6:03 am Stephen Connolly stephen.alan.conno...@gmail.com wrote: I agree that adding bundled plugins just makes life more complex. In my view Jenkins would come bare bones empty... BUT you could upload a zip of plugins and Jenkins would

Re: Revisiting bundled plugins

On Wed, Aug 5, 2015 at 1:56 AM, Kohsuke Kawaguchi k...@kohsuke.org wrote: We add the following plugins and their dependencies: git parameterized-trigger workflow -1, no new bundled plugins. Then remove the following plugins: cvs (split from core in 1.340, 929KB) ant (split from core in

Re: Revisiting bundled plugins

Many times before some starting guide was discussed. IMHO better create starter-plugin that will provide some groups of plugins as Java/PHP/etc packs so user can easily choose what install. Or probably provide predefined sections like SCM that will dynamically provide i.e. 3 top installed scm

Re: Revisiting bundled plugins

+ Folders Plugin is good candidate as grouping entity for jobs hierarchy. On Wednesday, August 5, 2015 at 10:28:07 PM UTC+3, Kanstantsin Shautsou wrote: Many times before some starting guide was discussed. IMHO better create starter-plugin that will provide some groups of plugins as

Re: Revisiting bundled plugins

I'm not really sure what the difference is between a bundled and non-bundled plugin (is it just that the same plugin but stored in the WAR file rather than a standalone file?) Assuming it was more or less just a matter of adding plugins into the WAR file, then I'd be in favour of having two

Re: Revisiting bundled plugins

O and I forgot a point: Let's fix the nightmare created by pinned plugins at the same time. It is a concept really difficult to understand for users. On Wed, Aug 5, 2015 at 10:49 PM, Arnaud Héritier aherit...@gmail.com wrote: I agree about this need to remove as such as stuffs as possible

Re: Revisiting bundled plugins

And if it is for next Xmas: Don't forget all users who are deploying Jenkins in a environment with no internet (or a limited access). Thus if we could pack together some set of plugins (and required dependencies) and allow jenkins to eat them. Deploying plugins one by one is a nightmare and error