an extension is bom

[Alex Heneveld <al...@cloudsoftcorp.com>]

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 
"catalog.bom" or "*.catalog.bom"?

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.

     single-node.bom
     cluster.bom

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

     catalog.bom

and then in your brooklyn you just point at this file (a url in github, 
or maybe even the project root, with `catalog.bom` 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 catalog.bom makes it clear things are 
catalog entries, whereas anything-else.bom 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

Re: an extension is bom

[Andrew Kennedy <an...@cloudsoftcorp.com>]

+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 cluster-catalog-entry.bom or nginx.bom, where appropriate.

Andrew.
--
-- andrew kennedy ; clocker.io project founder ; @grkvlt ;

On 27 March 2015 at 18:50, Alex Heneveld <al...@cloudsoftcorp.com>
wrote:

>
> 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
> "catalog.bom" or "*.catalog.bom"?
>
> 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.
>
>     single-node.bom
>     cluster.bom
>
> 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
>
>     catalog.bom
>
> and then in your brooklyn you just point at this file (a url in github, or
> maybe even the project root, with `catalog.bom` 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 catalog.bom makes it clear things are catalog
> entries, whereas anything-else.bom 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
>
>