Parent Packaging POM: Support for exporting a plugin manifests file

[oleg-nenashev]

JFR Packaging POM currently prepares a Jenkinsfile Runner bundle (appassembler ZIP) where plugins are included into the bundle. They are available in the classpath, but JFR Plugin Manager cannot recognize the plugins because of the missing plugin Manifest resources. After that, API like PluginManager#getPlugin(String) do not work properly and cause random issues in plugins. It would be nice to have a way to read proper manifests of plugins included into classpath.

Acceptance criteria

• There is a build step which generates a manifest file for plugins passed as dependencies. Maybe it should be implemented as a new mojo in Maven HPI Plugin
• Manifest file has a machine readable format. It maybe an update center JSON or a new YAML definition
• Manifest file is documented in the JFR Packaging POM readme

References

• Manifest Generation Code in Maven HPI Plugin
• Integrated Manifest generation in https://github.com/jenkinsci/maven-hpi-plugin/blob/602d838752ba7f83ed2d2f0b415b2900ba5563fc/src/main/java/org/jenkinsci/maven/plugins/hpi/BundlePluginsMojo.java[BundlePluginsMojo]
• Update Center JSON sample

Example MANIFEST file

Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Built-By: Oleg
Build-Jdk: 1.8.0_201
Extension-Name: promoted-builds
Specification-Title: The Jenkins Plugins Parent POM Project
Implementation-Title: promoted-builds
Implementation-Version: 3.6
Group-Id: org.jenkins-ci.plugins
Short-Name: promoted-builds
Long-Name: Jenkins promoted builds plugin
Url: https://github.com/jenkinsci/promoted-builds-plugin
Compatible-Since-Version: 3.0
Minimum-Java-Version: 1.8
Plugin-Version: 3.6
Hudson-Version: 2.121.1
Jenkins-Version: 2.121.1
Plugin-Dependencies: rebuild:1.31;resolution:=optional,project-inherit
 ance:1.5.3;resolution:=optional,maven-plugin:3.2;resolution:=optional
 ,apache-httpcomponents-client-4-api:4.5.3-2.1,config-file-provider:2.
 18;resolution:=optional,credentials:2.1.4,job-dsl:1.74;resolution:=op
 tional,junit:1.20,script-security:1.54,ssh-credentials:1.13,structs:1
 .19,token-macro:2.0;resolution:=optional
Plugin-Developers: Kohsuke Kawaguchi:kohsuke:,Peter Hayes:petehayes:,O
 leg Nenashev:oleg_nenashev:

[oleg-nenashev]

Such file could be also a resolution for https://issues.jenkins-ci.org/browse/JENKINS-48885 in Jenkins Test Harness. It makes a JSON format preferable so that we do not need to include YAML libs into the developer tooling

[sladyn98]

@oleg-nenashev So if I understand correctly in order to get this solved JFR needs to have a build step that generates a manifest file(update center JSON) that plugin manager can then pick up.

Question: In order to implement the build step in the maven hpi plugin we would need to read the dependencies from the manifest file right ? Would this mean submitting a patch to maven HPI plugin modifying the generation of the manifest ?

Alternative: Could we read it from the class path and generate the manifest ourselves ?

[oleg-nenashev]

In order to implement the build step in the maven hpi plugin we would need to read the dependencies from the manifest file right ?

No, you would not. Maven HPI Plugin is the thing which generates this file. You do not need to implement file roundtrips, all the logic is already there.

Would this mean submitting a patch to maven HPI plugin modifying the generation of the manifest ?

Likely. Note that plugin manifest file may have two meanings: MANIFEST.MF for HPI files, and a standalone file for multiple files. Here I mean the latter

Could we read it from the class path and generate the manifest ourselves ?

It might be possible to extract existing files and put them somewhere accessible to the resource classloader.

[oleg-nenashev]

oleg-nenashev/lib-bom-jep309#1 as a foundation lib