On Thursday, September 17, 2015 at 11:16:41 AM UTC+1, Daniel Beck wrote: > > > On 17.09.2015, at 11:26, Tom Fennelly <[email protected] <javascript:>> > 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 the > bundled version (in /WEB-INF/detached-plugins). > > Yep, it looks like that's what Jesse is arguing for. I'd have kept pinning > around for now, but it looks _really_ unpopular. It's basically what we > discussed a few days back, without the pinning. >
So this is what's in the PR then, minus the pinning. I'm fine with removing pinning, but would be interested to know why it's so unpopular? There seems to be a strong logic to it's existence and not liking doesn't seem like a good reason to ditch it. > > Regarding your proposal, note that there are detached plugins that have > since picked up dependencies. Those dependencies would also be in > detached-plugins/ right? > Right, I outlined that in the post I made here yesterday ... detached plugin dependencies (and dependencies of dependencies etc) are deployed if that detached plugin is deployed (it gets that info from the manifest). Dependencies must also be in the /WEB-INF/detached-plugin folder in the war. > Not sure we should keep plugins/ -- probably. Ideally official Jenkins > would come without any. (Which means we'd lose Translation Assistance... > not sure what a good solution is here...) > I think this should stay for now at least (and so does KK). For one thing, the new approach to JavaScript modularization (which these changes are using - and will be used in other ui enhancements) uses plugins to bundle JavaScript "bundles" (see here <https://github.com/tfennelly/jenkins-js-builder>). Yes, jenkins modules etc etc, but they do not allow easy upgrade and require what I consider to be ugly hacks in order to make the web resources available (UnprotectedRootActions etc sorry ... yeuck). It seems to me like there's a problem here in that all plugins are treated equally when they really are not all equal. Some plugins provide actual "features", while other plugins are just "dependency" plugins (call them what you like) and are dependencies of "feature" plugins OR Jenkins core itself. I'd think it makes sense to allow these "dependency" type plugins to be bundled in Jenkins core, but not the "feature" plugins. Jenkins modules could work instead of some of these "dependency" plugins, but not them all because of the updating issue with modules (you need a new Jenkins). -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4c16b781-477c-46d5-849f-5123ac8d4b69%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
