If I might throw in another tech, which hasn't been talked of yet. Another possibility would be to take a look at CDI, we have pax-cdi which does a fair share of leveraging cdi stuff in osgi and afaik someone from IBM started to work on something to have cdi 2.0 be compatible to OSGi. Especially the dynamics. Never the less pax-cdi does already work quite nicely with it, the only drawback because the company initially working on the RFP 148 lost interest in it, it never happend to be finished. Maybe this will change with the cdi 2.0 approach.
regards, Achim 2016-03-21 10:28 GMT+01:00 Richard Nicholson <puppy_wants_a_...@me.com>: > np > > > On 21 Mar 2016, at 09:25, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > > > > Hi Richard, > > > > Thanks again for your help, much appreciate ! > > > > Let me send a private e-mail to you (copy with people involved in the > decision in my company). > > > > Thanks ! > > Regards > > JB > > > > On 03/21/2016 10:20 AM, Richard Nicholson wrote: > >> JB - > >> > >> As I directly offered to you during our discussion in 2015 - if I can > help in any way please let me know. Myself and other OSGi Board Members are > more than happy to help any company that is considering joining the OSGi > Alliance. > >> > >> Best Wishes. > >> > >> > >>> On 21 Mar 2016, at 09:04, Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > >>> > >>> Hi Richard, > >>> > >>> we already had discussion with the OSGi Alliance. Christian and I > asked if it would be possible to work on specifications "outside" of our > company first, as OpenSource guys. It seems very difficult, so now, we are > discussing internally with our company. > >>> > >>> Regards > >>> JB > >>> > >>> On 03/21/2016 09:53 AM, Richard Nicholson wrote: > >>>> > >>>>> On 21 Mar 2016, at 08:27, Christian Schneider < > ch...@die-schneider.net> wrote: > >>>>> > >>>>> Indeed it is difficult to predict where the OSGi community will go > in the future. > >>>> > >>>> No great mystery, no crystal ball need and easily addressable. > >>>> > >>>> Companies making profit out of the Karaf community (selling services > wrapped around it, or training based upon it), also companies using Karaf > based solutions in their production systems and worried about longevity, > should both join the OSGi Alliance. > >>>> > >>>> Get involved, commit resources to drive forwards specifications that > you want to see. That is how the Alliance operates. DS has moved forwards > precisely because OSGi Alliance members have put the effort in to do this. > >>>> > >>>>> > >>>>> For DS the situation is hopefully a little better today than at the > time I did the comparison. > >>>>> - JPA can be solved today by using the Aries JPA and JPATemplate but > it is not standardized. The upcoming spec hopefully will improve this. > >>>>> - Services and Remoting can be solved by Remote Service Admin. With > ECF and Aries rsa (CXF-DOSGi) there are now two stacks available on karaf > that can help with this. > >>>>> Still it can be a little rough if you want to use some special CXF > features. We will have to prove using some good examples / pocs that Remote > Services can fully replace the blueprint CXF namespaces. > >>>>> > >>>>> Btw. I have some plans for Aries RSA to support application wide > policies. The idea is to define some common aspects of your services > centrally and apply them to all exported OSGi services. So for example you > could define in one central point that all your services with JAXRS > annotations should be auto exported and have single sign on authentication > using STS, SSL encryption and logging. > >>>>> > >>>>> The migration though is still a big issue. > >>>>> > >>>>> Some time ago I did the migration of a medium sized production > system from servlet container + spring to karaf + blueprint. The big > problem there was that we had to do the transition > >>>>> while the main team was going full steam and doing releases. It was > the start of the blueprint-maven-plugin as this was the only way to do > migration without a big bang. So if you > >>>>> have to do this then the annotation based approach + the plugin > above can help a lot. If someone wants to try this I can help with some > good advices. If there is some interest I can also blog about > >>>>> how to do such a transition in practice. > >>>>> > >>>>> A migration to DS will pretty much be a big bang as it is too > different from spring to do a smooth transition. I think it is possible to > do a full business application in DS but the migration step is bigger. > >>>>> > >>>>> Christian > >>>>> > >>>>> On 21.03.2016 02:24, Tim Jones wrote: > >>>>>> Andreas you are crossing or about to cross a bridge we are crossing > at the > >>>>>> moment. We also have a SpringDM based application. It is 3+ years in > >>>>>> production and so a change as large as moving away from SpringDM is > very > >>>>>> disruptive. For the most part we considered only Aries Blueprint vs > DS. > >>>>>> However as you can see from this post there are other alternatives, > some > >>>>>> fairly recent such as support for Spring namespaces in Aries > Blueprint. > >>>>>> > >>>>>> For us the most significant points to consider were > >>>>>> > >>>>>> 1) Will there still be good support in 5-10 years (having been > burnt once we > >>>>>> don't want face the same issue again) > >>>>>> > >>>>>> 2) Where is the general OSGi community heading? Blueprint/DS/other. > The > >>>>>> first sentence of Tim Ward's post is something we thought > significant. > >>>>>> Something that has concerned me over the last couple of years is > sometimes > >>>>>> an alternative is suggested by needs some jiggery pokery to make it > work, it > >>>>>> doesn't have wide support, little documentation, often has bugs > which led to > >>>>>> a churn of releases. While it may be a cool, clever solution we > aren't going > >>>>>> to bet our production system on cool and clever only. > >>>>>> > >>>>>> 3) We are by and large glue coders and don't have the ability nor > want to > >>>>>> spend the time/resource building our own custom solutions, this is > where I > >>>>>> think Spring has suited us well until now. We tried to identify what > >>>>>> offerings were available for the bits we needed e.g. JPA, JDBC, > >>>>>> transactional control, Camel JMS, CXF. It is an opinion only, but > from what > >>>>>> I could see Blueprint offered the broadest support (see Christian's > >>>>>> ecosystems-compared > >>>>>> > http://www.slideshare.net/mfrancis/osgi-ecosystems-compared-on-apache-karaf-christian-schneider > ). > >>>>>> > >>>>>> The big one for us was lack of JPA/JDBC/transactional control for > DS, while > >>>>>> there were some solutions we wanted something with a 'spec behind > it'. This > >>>>>> is currently been worked on at the moment > >>>>>> (https://github.com/apache/aries/tree/trunk/tx-control) and I > think it is a > >>>>>> significant piece of work that will make DS a much more attractive > >>>>>> proposition in the enterprise/applications space. Admittedly there > is a risk > >>>>>> in being new adopter however we think the risk is worth it in this > case. > >>>>>> Camel has a recent DS offering camel-scr (although I think there > are some > >>>>>> issues with it). Hopefully in time more libraries will offer DS > support out > >>>>>> of the box. > >>>>>> > >>>>>> 4) We are not yet sure we will be able to fully realise the pros of > the > >>>>>> service dynamics that DS offers vs Blueprint as although one of our > goals is > >>>>>> to be able to 'hot swap' bundles into a running system this may be > harder to > >>>>>> achieve than we had hoped. We currently do some limited hot > swapping with > >>>>>> our SpringDM system. > >>>>>> > >>>>>> 5) Perhaps counter intuitively of less importance to us was the > actual ease > >>>>>> of transition, Blueprint would almost certainly be easier to > migrate to from > >>>>>> SpringDM but we think that this is a one off cost that will be > outweighed in > >>>>>> the long term. > >>>>>> > >>>>>> Tim > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> View this message in context: > http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845p4045892.html > >>>>>> Sent from the Karaf - User mailing list archive at Nabble.com. > >>>>> > >>>>> > >>>>> -- > >>>>> Christian Schneider > >>>>> http://www.liquid-reality.de > >>>>> > >>>>> Open Source Architect > >>>>> http://www.talend.com > >>>>> > >>>> > >>> > >>> -- > >>> Jean-Baptiste Onofré > >>> jbono...@apache.org > >>> http://blog.nanthrax.net > >>> Talend - http://www.talend.com > >> > > > > -- > > Jean-Baptiste Onofré > > jbono...@apache.org > > http://blog.nanthrax.net > > Talend - http://www.talend.com > > -- Apache Member Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead blog <http://notizblog.nierbeck.de/> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> Software Architect / Project Manager / Scrum Master
