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
