The use case is the following:

A plugin depending on a 'commons' jar, that depends on other jenkins plugins.

The hpi plugin currently supports:

• direct plugin dependency
• transitive plugin dependency through another plugin
  And it excludes transitive jar dependencies involved in these branch layouts, since they are supposed to be packaged within their corresponding plugins, and classloading is set up appropriately at runtime.

But not the use case I described.

The plugin packages:

• the commons jar,
• any transitive (compile/runtime) jar dependency from transitive plugins.
  The transitive plugins are also missing from the resulting manifest, so to get a working classloader, the plugin needs to re-include these plugins to have a working environment.

To support this use case, the maven-hpi-plugin should:

• consider transitive plugin dependencies through any other packaging, and exclude their own dependencies
• pick up transitive plugin dependencies through non-hpi dependencies and include them in the plugin manifest.