I'm sure this subject was already discussed on the mailing list and within the Brooklyn community, but I do have some questions and some thoughts on how to enhance the current state of affairs.
PROPOSAL My proposal is, in short, to shift the architectural focus of Brooklyn towards a plugin-based implementation, in my view supported by OSGi. In detail, I'd suggest deploying the brooklyn core, the REST server and the web console as separate bundles inside an OSGi container, allowing for locations, entities and blueprints to be plugged in as separate bundles. With the above in mind, we can create an online catalog of OSGi bundles that can be added to a running brooklyn instance. Each bundle can be maintained separately, possibly by 3rd parties, and submitted to the central catalog for testing and validation before being published. PREMISE I based my proposal on the knowledge I could gather by browsing the documentation available on site, the examples supplied with the brooklyn project in the example folder and other projects at https://github.com/brooklyncentral. These I believe to be the resources any new contributor would come in contact with. I managed to coalesce that there are currently 3 possible ways of extension: 1. deriving a new project from brooklyn-downstream-parent (such as clocker, brooklyn-ambari, brooklyn-spark, and the examples shipped within the brooklyn source code). This way is implicitly endorsed by the brooklyn maven archetype. 2. create a "dropin" to be placed in $BROOKLYN_HOME/lib/dropins, such as brooklyn-location-azure-cli. Unfortunately the project seems to be stagnant, and there is no documentation about dropins. 3. fork the incubator-brooklyn project for personal use, perhaps contributing changes to the apache repository Are there any other ways? The first procedure newcomers run into is #1, which is quite disconcerting, because - it lacks the opportunity for composability (to deploy spark with clocker we'd need a new project, brooklyn-spark-clocker, or maybe brooklyn-clocker- spark) - it prevents 3rd parties from contributing their work back to the community Mechanism #3 does not scale well with regard to the community, since users can only collaborate via the main brooklyn repository. Mechanism #2 seems best from a technical point of view, but is not advertised and documented at all. Also, it suffers from dependency versioning problems already addressed by OSGi. Implementing the main extensibility mechanism via OSGi would allow independent development of various entities and blueprints, therefore allowing the community to grow faster. It also addresses the problem of upgrading entities separately within a running brooklyn instance, instead of the need to restart the entire application. Each bundle (entity, location) can be subject to a set of automated tests, have reports automatically generated and presented in the online catalog. Thank you, Ciprian
