brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Kennedy <>
Subject Re: an extension is bom
Date Sat, 28 Mar 2015 15:40:25 GMT
+1 Yes, this is a good idea, Alex.

I had also been thinking somewhat along these lines recently. Since we
often see GitHub repos with a Dockerfile and Vagrantfile in their root now,
it makes sense to have an analogous Brooklyn file. What about just calling
it a Brooklynfile and leaving it at that? I know that would mean you need a
separate directory for each catalog entry if they are to use the defauylt
name, but we could support named BOMs, like ClusterBrooklynfile or
WebBrooklynfile perhaps. And there can also be an alternative of names with
extensions, like or, where appropriate.

-- andrew kennedy ; project founder ; @grkvlt ;

On 27 March 2015 at 18:50, Alex Heneveld <>

> brooklyners,
> what do people think of adopting the convention of a ".bom" suffix for
> brooklyn yaml blueprints?
> and of allowing multiple items in a catalog file, for which we'd use
> "" or "*"?
> my thinking is that calling blueprints *.yaml makes them hard to find and
> recognise, whereas ".bom" -- which could stand for "brooklyn object
> manifest" -- would make that simpler.  of course it's a play on "bill of
> materials" as well as the maven "pom" (project object model), and will
> enable endless puns (drop your bom into brooklyn) and the homoglyph fun we
> can now have (almost as good as clocker, and not so unfortunate as in the
> case of maven!)
> more usefully the idea is then that a project might include one or more
> *.bom files in their root, alongside the pom, e.g.
> and it's clear that these are easy ways to deploy it, analogous to the
> pom.xml as a standard way to build a project.
> turning to the catalog, the standard might also be for a project to
> include a
> and then in your brooklyn you just point at this file (a url in github, or
> maybe even the project root, with `` inferred) to add a
> selection of catalog items for that project to your brooklyn.  (we could
> introduce a different extension for catalog items but i'm inclined to think
> the convention ending makes it clear things are catalog
> entries, whereas is a straight-up blueprint, and it keeps
> things simpler.)
> feedback welcome.  i hope to be sending a PR for this in the next few days.
> best
> alex

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message