danielbeck
Agreed, unbundling still can be implemented. I should have googled for the implementation a bit. On the other hand, there are still some cases, where plugin bundling may be useful. As teilo mentions in JENKINS-36583, plugin bundling is something we still mention in documentation. Such bundling engine may be still useful for particular Jenkins users, who package their own distributions to whatever reason.

The proposed PR in https://github.com/jenkinsci/jenkins/pull/2436 offers an engine, which allows specifying plugin dependencies in WAR files with deployment process being managed by system properties (required plugin and enforced plugin versions). It brings in some extensibility for various Jenkins configurations, which can be deployed from the same WAR.

Would be such engine useful?

Right, the Jenkins wiki still mentions custom wars etc., but I'm wondering what's missing, besides restoring e.g. pinning, to enable that well.

IMHO Pinning does not really need to be restored. Enforced plugin versions should work better for it. But I can restore pinning in my PR as well

Then it's not clear to me why anything needs to be done to get…

• Would allow bundling of Jenkins plugins into Jenkins WAR file
• Install the plugin if it's not installed during the startup (if it's not disabled)
• Allow updating the version above the bundled one

because AFAIU we already have all of that from Jenkins 1. Pinning takes care of the third item on the list, and the rest should be free…?

To clarify, I'm not saying "no", I'm saying "why?".

danielbeck pinning (as implemented) was always a PITA as when you upgraded a war with newer set of bundled plugins you could get some updates but not all (if an individual plugin had been updated it would then be pinned) this could cause issues if one of the updated plugins required the updated plugin that was pinned.

I would think a simpler approach of update if installed is older (JENKINS-36583) should be an achevable minimum, whilst the relative merrits of this issue are discussed / understood. WDYT?

I would think a simpler approach of update if installed is older

There is (was?) an admin monitor for that. I have concerns about unexpected plugin updates.

The rationale for the two system properties and the 'force plugin version' behavior in the PR also seems to be completely missing from this issue.

The PR claims that the JIRA issue has a description of the ultimate use case, but I guess I am not seeing it here. What does

it's impossible to safely unbundle Core functionality

refer to, concretely? What does “unbundle core functionality” mean? Splitting plugins from core? That is handled by the detached list.

Yep I do not understand this or the PR

I'll follow-up on it after my vacation

I didn't. I have no interest in delivering it during my spare time, hence I am just going to close it