Mailing-List: contact dev-help@brooklyn.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.apache.org
From: aledsage <git@git.apache.org>
To: dev@brooklyn.apache.org
Reply-To: dev@brooklyn.apache.org
References: <git-pr-485-brooklyn-server@git.apache.org>
In-Reply-To: <git-pr-485-brooklyn-server@git.apache.org>
Subject: [GitHub] brooklyn-server issue #485: `BundleMaker` utility routines making it easy to...
Content-Type: text/plain
Message-Id: <20170228173057.E9554DFDB1@git1-us-west.apache.org>
Date: Tue, 28 Feb 2017 17:30:57 +0000 (UTC)
archived-at: Tue, 28 Feb 2017 17:31:00 -0000

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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---