It was requested that the tool share a cache with ~/.m2/repository.

Discussion with jglick:

> Couple of questions about @jglick’s comment about sharing a cache with the ~/.m2/repository/. 1) Would all plugins be in the following path: ~/.m2/repository/io/jenkins/plugins/? 2) When you say “share a cache” do you mean that plugins wouldn’t have to be downloaded and they could just be copied over to the plugin directory Jenkins uses? Or that Jenkins would actually look to the ~/.m2 directory for some of its plugins? Or maybe you’d have something like a soft link ?

> @stopalopa by sharing a cache I would mean that any time your tool was looking to download a specific version of a specific plugin, it would first check ~/.m2/repository/ and use that copy instead; and, if possible, conversely if it did need to download a plugin, it would save it in the Maven local repository where it would be available without an Internet connection for both this tool and any Maven build. (The latter part is harder, since to write the associated metadata files correctly and work with mirror settings in ~/.m2/settings.xml you need to embed a Maven library.) The group ID is not in general predictable (org.jenkins-ci.plugins and io.jenkins.plugins are the two most common), but if I recall correctly is defined in both an actual plugin archive (*.jpi) as well as the update-center.json from the Jenkins UC.

For context, this is an example of a DiY system I have used in the past out of frustration with the limitations of install-plugins.sh (both the lack of cache sharing with Maven, and the fact that it picks up transitive plugin dependencies in nondeterministic versions acc. to whatever is on the UC that day): https://github.com/jenkinsci/parallel-test-executor-plugin/blob/f50c3d8b8a7d3223e8575247ff4303975aa293e0/demo/pom.xml#L32-L213 (which could now be simplified using https://github.com/jenkinsci/bom/#usage) and https://github.com/jenkinsci/parallel-test-executor-plugin/blob/f50c3d8b8a7d3223e8575247ff4303975aa293e0/demo/Makefile#L8-L17