np
> On 21 Mar 2016, at 09:25, Jean-Baptiste Onofré <[email protected]> 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é <[email protected]> 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 <[email protected]>
>>>>> 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é
>>> [email protected]
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>
>
> --
> Jean-Baptiste Onofré
> [email protected]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
