Christian, I think one other problem with DS is that so much of the literature is about here's how to start up a component and why we should prefer that and how the annotations work. In the enterprise world, as you are aware, we have a lot of concerns like how do I set up my CXF endpoint, DS, Camel routes, properties/cfg, ensure that my services are all accounted for when things run, have easy test-ability and deployment, versioning, etc. The OSGi community has been so closely focused on DS that I wonder if that larger world and use case doesn't get lost.
I mean your comment says a lot: "I recently tried to make camel work with DS and found that the DS support camel provides is quite complex and does not work well." Part of the issue there too is that Camel is a Swiss Army knife for both good and ill. Reading through the documentation one has to be able to switch between reading XML and Java DSL and that feels like reading Latin and then switching to Greek. That and there is something not quite right about the Camel Java DSL. I'd love to be able to embrace it and have tried to on multiple occasions. But recently I was working with it again and I always feel like I'm wearing a straight jacket with it. You get stuck in the fluent builder. As much as I dislike XML and working with it at least the flow feels right to me, a route is invoking logic on a Java handler in a typed fashion and that makes it easy to unit test. On Fri, Jul 8, 2016 at 6:03 AM, Christian Schneider <[email protected] > wrote: > I think one really big problem with the OSGi specs is that only people > working for an OSGi alliance member can work on specs. > Especially in the open source world there are a lot of motivated people > with good knowledge but if their employer is not an OSGi member these > people can not work on any spec. > So while I can understand that only the OSGi members decide about the > specs in the end I think the OSGi alliance must open itself more for > individuals who are offering to help. Only in this way > the OSGi alliance can keep up with the dynamics of open source. > > Having saig all this I am not sure though if it would really help with > blueprint. In the case of blueprint my impression is that it has grown too > complex while still having some severe drawbacks in practice. > > So I myself are currently looking more into DS as it is simpler and has > less issues with all the OSGi dynamics. I think DS might need a defined > extension model but in its core I really like that > it kept being quite simple. > > Christian > > > On 08.07.2016 12:37, David Bosschaert wrote: > > Hi Brad, > > On the 'Blueprint is dead' discussion... There are a number of RFCs in > OSGi about improving blueprint [1][2][3][4][5], but they have not made it > to the specs yet because those pushing them forward ended up being > reassigned to other work. Anyone who is a member of OSGi can certainly pick > those up and bring 'Blueprint back to life'... OTOH a lot of work has gone > into Declarative Services over the recent past so if someone was to start > from scratch it would make most sense to use DS today... > > Best regards, > > David > > [1] https://github.com/osgi/design/tree/master/rfcs/rfc0155 > [2] https://github.com/osgi/design/tree/master/rfcs/rfc0156 > [3] https://github.com/osgi/design/tree/master/rfcs/rfc0164 > [4] https://github.com/osgi/design/tree/master/rfcs/rfc0166 > [5] https://github.com/osgi/design/tree/master/rfcs/rfc0184 > > On 8 July 2016 at 11:24, Brad Johnson <[email protected]> > wrote: > >> David B, >> >> Thanks. Part of the reason I brought this to this thread was another >> gentleman on the Camel mailing list was trying to figure out how to share >> configurations across his bundles and wondered if the PID mechanics of >> blueprint were usable or if there were a way to do it via blueprint. David >> J pointed out that the multilocation mechanism was the way. But I hadn't >> heard of that being implemented or available via blueprint. That's when >> the "blueprint is dead" discussion started. >> >> Brad >> >> On Fri, Jul 8, 2016 at 3:50 AM, David Bosschaert < >> <[email protected]>[email protected]> wrote: >> >>> Hi Brad, >>> >>> In OSGi currently the concept of a Configurator is being developed. It's >>> orthogonal to Blueprint or DS and can be used with either of them. It might >>> touch on the ideas that you mentioned here. You can find the current >>> configurator design in RFC 218: >>> <https://github.com/osgi/design/tree/master/rfcs/rfc0218> >>> https://github.com/osgi/design/tree/master/rfcs/rfc0218 >>> Maybe this might be something that could be of use. >>> >>> Additionally, the OSGi ConfigAdmin spec permits the same configuration >>> to be consumed by multiple bundles. That might also be of use to you if you >>> want to share configurations. The bundle location for the configuration >>> should be set to '?' in that case (see Config Admin spec 104.4.1). >>> >>> Cheers, >>> >>> David >>> >>> PS feedback on the RFC is appreciated, see here: >>> https://github.com/osgi/design >>> >>> On 7 July 2016 at 18:53, Brad Johnson < <[email protected]> >>> [email protected]> wrote: >>> >>>> As I work in more environments now that want to use microservices the >>>> limitations of the blueprint properties mechanics become a bit hairier. I >>>> commonly find that I have bundles that have common properties shared across >>>> them and I can't find a good solution other than creating my own OSGi >>>> service for serving them up for such crosscutting concerns. >>>> >>>> I'm not an expert on the specification and implementations of >>>> compendium or blueprint libraries so don't know how feasible something like >>>> this would be but I would find the following terribly useful. >>>> >>>> A properties hierarchy much like Maven that permits you to specify a >>>> parent that you inherit from and then can add to or override. >>>> >>>> com.foo.parent.cfg >>>> com.foo.child.cfg >>>> >>>> The child cfg file might have a #! directive at the top specifying >>>> com.foo.parent PID. And if another one was >>>> >>>> com.foo.grandchild.cfg >>>> >>>> it might specify com.foo.child as its parent. Then the CM would load >>>> parent, override it with child and finally override that grahdchild. >>>> >>>> Yes, I'd still have to specify >>>> >>>> <cm:property-placeholder persistent-id="com.foo.granchild" >>>> update-strategy="reload"> >>>> >>>> in my bundle and that would still be bound to that single bundle but >>>> this could alleviate the need for replication of properties across a lot of >>>> bundles. >>>> >>>> Technically that is all rather straightforward but I'm not sure how >>>> well that would align with the specifications or goals of CM. >>>> >>>> Brad >>>> >>> >>> >> > > > -- > Christian Schneiderhttp://www.liquid-reality.de > > Open Source Architecthttp://www.talend.com > >
