Re: Bundles in Brooklyn

2017-06-23 Thread Richard Downer
Hi Aled, On 22 June 2017 at 18:51, Aled Sage wrote: > _*Business Case (aka value to end-users)*_ > It would be good to be clearer on the user-value we deliver from this (but > please shout if others think that is already clear enough). > I have a fairly simple use case. At the moment (and I may

Re: Bundles in Brooklyn

2017-06-23 Thread Alex Heneveld
Aled- Hi -- inline On 22/06/2017 18:51, Aled Sage wrote: +1 to this approach, but I suspect there's a lot more to discuss/plan. Great list of questions. We don't need these solved now for the immediate proposal but I think we are reaching a consensus even on tricky longer-term issues which

Re: Bundles in Brooklyn

2017-06-22 Thread Aled Sage
+1 to this approach, but I suspect there's a lot more to discuss/plan. _*Leaking OSGi*_ I agree with Geoff's worry of us "leaking OSGi". However, we should just "leak" the semantics of bundle dependencies and versioning, which need to be explained to the user. I think we can avoid exposing the

Re: Bundles in Brooklyn

2017-06-21 Thread Geoff Macartney
hi Alex, that sounds fair enough. We'll want to add good documentation around what it means if *everything* is now a bundle (and how we wrap plain catalogs into bundles on users' behalf). We can use the text of your email as a starting point for the docs; it would be good to explain some of the

Re: Bundles in Brooklyn

2017-06-20 Thread Alex Heneveld
Hi Geoff Thanks. Replies to specific points: > whether we are "leaking" an implementation detail (the fact that we use an OSGI runtime) My motivation was to try to minimize this leak. The fact that we use OSGi internally for dependency isolation forces us to use OSGi versions with bundles

Re: Bundles in Brooklyn

2017-06-20 Thread Geoff Macartney
hi Alex, In general I think this is a good direction to go in, some questions and thoughts below. One concern is whether we are "leaking" an implementation detail (the fact that we use an OSGI runtime) into the specification of what Brooklyn is. I think it is good to aim for the improved modular

Re: Bundles in Brooklyn

2017-06-20 Thread Alex Heneveld
Richard- Good points. To your questions: > Is it necessary to always wrap stuff in a bundle? No, and currently we don't. But I think the model becomes clearer if we do, all catalog items (registered types) are contained in a bundle. Note that this gives us a way to preserve an uploaded `c

Re: Bundles in Brooklyn

2017-06-20 Thread Richard Downer
Alex, On 19 June 2017 at 17:39, Alex Heneveld wrote: > With bundles now being neatly supported for add and remove, I think it > makes sense to use make the "bundle" a first-class concept in managing a > brooklyn catalog (type registry). > A great proposal. The blueprint developer stories in Bro

Bundles in Brooklyn

2017-06-19 Thread Alex Heneveld
Hi All- With bundles now being neatly supported for add and remove, I think it makes sense to use make the "bundle" a first-class concept in managing a brooklyn catalog (type registry). The basic idea is that users will work with ZIPs (or directories if using the br CLI), where a "catalog.b