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.
