Github user aledsage commented on the issue:
https://github.com/apache/brooklyn-server/pull/485
@ahgittin agree there is 100% support on the direction.
There was push-back on what exactly the REST API piece should look like:
* @geomacy suggested that we should only support a zip that had a valid
MANIFEST.MF file, and that the `br` command could auto-generate that manifest
to make the user's life simpler.
* @neykov asked why we should require the bundle symbolic name and version
being passed at all, suggesting they could be inferred from the the catalog.bom
in some way (most likely with additional metadata).
It also sounded from the mailing list thread like enabling
`BrooklynFeatureEnablement.FEATURE_LOAD_BUNDLE_CATALOG_BOM` could be
fiddly/hard (to make it work in HA mode, on rebind, etc).
It would be good to separate out the two (or three?) things that this PR
does so that we can merge them incrementally, rather than them all being
blocked until there's consensus on everything:
1. The underlying building blocks for manipulating bundles etc could get
merged asap.
2. The changes to the REST api seem like they need more discussion on the
mailing list.
We should also discuss on the mailing list more about how
`FEATURE_LOAD_BUNDLE_CATALOG_BOM` should really work - e.g. how will we solve
the HA/rebind issues. And we should write down (on the mailing list) what
exactly will be supported for such bundles - presumably "just" reading a root
`catalog.bom` file; this would reference other things in the bundle using
`classpath://...` which is an ugly java'ism, but a good starting point.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
