brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Heneveld <alex.henev...@cloudsoftcorp.com>
Subject an extension is bom
Date Fri, 27 Mar 2015 18:50:47 GMT

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


Mime
View raw message