Mailing-List: contact dev-help@brooklyn.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.apache.org
Subject: Re: Blueprint project structure
To: dev@brooklyn.apache.org, Geoff Macartney <geoff.macartney@cloudsoft.io>
References: <1cc638ca-a18e-140b-07c0-7818913e3469@cloudsoft.io>
 <CAE7C0PehJP3OK_WTJJKADBADfhKcdVAgHHHpKq3LnahtbN=rBA@mail.gmail.com>
From: Aled Sage <aled.sage@gmail.com>
Message-ID: <79c5b3dd-8c9b-e275-9441-65bf6fbf4a6d@gmail.com>
Date: Thu, 26 Oct 2017 13:36:56 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0)
 Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <CAE7C0PehJP3OK_WTJJKADBADfhKcdVAgHHHpKq3LnahtbN=rBA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
archived-at: Thu, 26 Oct 2017 12:37:04 -0000

Hi all,

I agree with Geoff: documenting the different approaches as you've done 
here sounds like the best way forward.

---
Note that:
     br catalog add 
https://github.com/brooklyncentral/brooklyn-dns/archive/master.zip
is not the same as:
     br catalog add target/brooklyn-dns-0.2.0-SNAPSHOT.jar

For the latter, the bundle has symbolic name 
"io.brooklyn.dns.brooklyn-dns" (which it gets from the way the pom.xml 
builds it as an OSGi bundle). The former has no bundle name, so gets an 
auto-generated anonymous bundle name.

I was assuming we would not tell people they must include `bundle: ` in 
the .bom file if they are explicitly building it as a bundle anyway. 
That is a violation of DRY (Don't Repeat Yourself). However, it would be 
necessary if we want to support adding via the zip and the jar.

Aled


On 25/10/2017 16:03, Geoff Macartney wrote:
> The phrase "win - win" springs to mind.
>
> I'm not sure we need to go quite so far as saying that 2 is always best
> practice.  I'd tend toward using your description as the basis for a new
> page in the docs that explains how projects can be structured and the
> significance of having the `catalog.bom` in the root position, and leaves
> it up to people to use what suits them.  If someone wants to use approach 1
> they shouldn't feel they're deviating from best practice.
>
>
>
>
>
> On Wed, 25 Oct 2017 at 15:58 Alex Heneveld <alex.heneveld@cloudsoftcorp.com>
> wrote:
>
>> Hi All-
>>
>> With the move towards bundles, people have been experimenting with
>> project structure, and there seem to be two schools:
>>
>> (1) use maven, include a `pom.xml` in root, and put the `catalog.bom`
>> and blueprints into either `src/main/resources/` or a custom resources
>> directory eg `catalog/`
>>
>> (2) put `catalog.bom` in root, and have yaml blueprint files, and
>> scripts and other resources, in whatever structure underneath makes sense
>>
>> Both have benefits.  For instance with (2) you can deploy straight from
>> the root, or even `br catalog add
>> https://github.com/brooklyncentral/brooklyn-dns/archive/master.zip`
>> <https://github.com/brooklyncentral/brooklyn-dns/archive/master.zip>, and
>> it's obvious where the entry point is.  With (1) you can build and
>> install to maven, and access the dependency as `mvn:...` URLs in karaf;
>> and it of course becomes very useful when including java.
>>
>> I've done some experimenting at [1] on a pom.xml configuration that
>> works with (2).   This means a blueprint developer can do what they like
>> without ever touching maven, not having a pom.xml, etc.  Then if they
>> want maven at some point it can be added on without having to change
>> anything else in the project.  It also means community blueprints can be
>> used as (1) or as (2), and people looking at them just look at the
>> subset of bom and yaml files that are the blueprint and it will be
>> sensible, without any odd structure imposed by maven.  And we can
>> encourage putting a `catalog.bom` in the root of every project on the
>> planet so there is never ever any question about how to deploy software
>> ever again.  :)
>>
>> Is this structure something we should converge on as a recommendation
>> for blueprints projects?  Basically I'm proposing we say (2) is _always_
>> best practice, even when is needed (1), and we have (one so far and more
>> to follow if we like this) exemplars for how to structure projects.
>>
>> Best
>> Alex
>>
>>
>> [1]  https://github.com/brooklyncentral/brooklyn-dns/pull/7
>>
>>