Re: Uploading ZIPs for a better dev workflow <- sharing bundles, not using karaf cellar?

hi Alex, My two cents - at a first glance 2a+b sounds good, but I will have a bit more of a think about it. On the point of your first P.S., there is a PR under review at https://github.com/apache/brooklyn-client/pull/44 cheers Geoff On Tue, 18 Apr 2017 at 16:12 Alex Heneveld

Re: Uploading ZIPs for a better dev workflow <- sharing bundles, not using karaf cellar?

Hi All- Great work on this. The one outstanding limitation is that bundles uploaded are not available to other nodes / after restart. I'd like to fix this so that we can shout loudly about this new feature. I had a look at Karaf Cellar which it synchronizes bundles among active karaf

Re: Uploading ZIPs for a better dev workflow

I just pushed a new PR[1] that is built on top of Alex's one[2]. This should cover all the point we discussed earlier Best. [1] https://github.com/apache/brooklyn-server/pull/608 [2] https://github.com/apache/brooklyn-server/pull/485 On Thu, 23 Mar 2017 at 11:27 Thomas Bouron

Re: Uploading ZIPs for a better dev workflow

Hi Aled, all. Sounds good to me. Once the PR is merged, I'll push on another one to fix the other issues I found in the past 2 days. I also agree with you on 2 and 3, I'll address that. Best. On Thu, 23 Mar 2017 at 11:02 Aled Sage wrote: > Hi Thomas, all, > > I think

Re: Uploading ZIPs for a better dev workflow

Hi Thomas, all, I think "bundle: ..." is actually a much better name to use in the catalog.bom than "symbolicName: ...". The latter makes sense to those who know OSGi, but otherwise doesn't suggest anything about "bundling". --- I think we're very close to merging [1] - further improvements

Re: Uploading ZIPs for a better dev workflow

some further thoughts: re. 1 I agree we should discriminate between the "symbolicName" of the bundle and use of the term "symbolicName" in the definition of catalog ids. (I'm not sure if just putting it into a "manifest" subsection will keep it separate, because of the use of "getFirstAs" at

Re: Uploading ZIPs for a better dev workflow

Having quickly scanned the thread I still don't see a reason why the requirement to have a consistent naming for the bundle itself which is not user visible? Could instead have behaviour similar to the machinNamer here. Slight preference for optional symbolicName when it's a jar file. Though I

Re: Uploading ZIPs for a better dev workflow

Considering the points made I'm pretty sure it's the case that requiring a symbolic name and version in the BOM presents little if any unnecessary burden, in which case I'm persuaded of the "one true way" philosophy. I really like it. :) Can anyone think of a case where it would be a

Re: Uploading ZIPs for a better dev workflow

It also means clients ('br' at least) can easily validate the upload even before execution by checking that all the manifest details are present. On Fri, 3 Mar 2017 at 09:57 Geoff Macartney < geoff.macart...@cloudsoftcorp.com> wrote: > Just on the last point of "We could also support the example

Re: Uploading ZIPs for a better dev workflow

Just on the last point of "We could also support the example below", I'd say let's not even be that flexible - my feeling is that the more flexible we are, the more confusing it is, and the harder to get right. If we're going to add this capability let's just have one way to do it; if you are

Re: Uploading ZIPs for a better dev workflow

Geoff, all, I was imagining the manifest version (in the catalog.bom) to be separate from the item version. The reason is that we support multiple items in the bom that can be independently versioned. Somone perverted could write: brooklyn.catalog: version: 1.0 manifest:

Re: Uploading ZIPs for a better dev workflow

I take Alex's point about the manifest being Java specific, and I agree therefore we shouldn't insist on it. +1 also to preferring explicit name/version in the catalog.bom rather than as API params, I agree we do need to keep the version in source control. Question on your straw man, does the

Re: Uploading ZIPs for a better dev workflow

Hi all, Discussion of the REST api kicked off again in https://github.com/apache/brooklyn-server/pull/485#issuecomment-283280366: Alex wrote: Requiring a MANIFEST.MF makes the input strongly java-centric; I'd like to appeal to people who write YAML blueprints with co-bundled

Re: Uploading ZIPs for a better dev workflow

> Svet, if instead we tried to infer it from the catalog.bom, would we require > some additional metadata within the .bom file? Or would we use the catalog > item's id + version? I'm not convinced by the latter - it would mean some > .bom files would work and others wouldn't (e.g. if the .bom

Re: Uploading ZIPs for a better dev workflow

Hi all, +1 (D) sounds good. What version are you imagining the bundle would be, if one runs `br catalog add ~/my/project/ --name com.example.myproject`? --- I like the idea of uploading a plain zip (rather than only supporting OSGi bundles) - that makes it simpler for non-java folk. The use

Re: Uploading ZIPs for a better dev workflow

hi Alex, this looks like a good feature to have, I shall look at the PR as soon as I can. The catalog.bom scanner feature was initially enabled by default, but we had to disable it because it turned out not to work properly with rebind. I don't think it should be a lot of work to fix that but it

Re: Uploading ZIPs for a better dev workflow

+1 Some thoughts: * (A) add a utility class BundleMaker Sounds very similar to https://ops4j1.jira.com/wiki/display/ops4j/Tinybundles Looking at the code it's much more focused on zip files so I guess there's no much overlap,

Uploading ZIPs for a better dev workflow

Hi Brooklyners- In the code we currently have two routes for users to install new blueprints: (1) upload a catalog YAML file to /v1/catalog (2) install a bundle with catalog.bom in the root The feature (2) is disabled by default, but I'd like to move towards enabling it. This will make it