I am a little bit confused about Blueprint and Spring DM:
From what I think is true:
Spring DM is a framework defined by Spring Source
Blueprint is a framework defined by the OSGi Alliance
Blueprint has "taken" many of it's ideas from Spring DM
No?
Can we expect that those two frameworks become one in the future (merge)? If not, which one will be the most future-proof?
OSGi 4.2 introduces the Blueprint Service specification based on
Spring Dynamic Modules project for which Spring DM (2.x) is the
Reference Implementation (RI).
In short: Blueprint is a specification, Spring DM is an implementation of Blueprint API
Blueprint was developed in the OSGi Alliance under the lead of SpringSource/Interface21.
However, if you're looking for a way to leverage OSGi use Declarative Services (DS) with annotations between bundles (services). In my experience, you do not really need the wiring XML when you make small cohesive bundles. DS is much better in working with services than Blueprint/Spring DM since they tend to to want to "hide" the dynamicity while DS just makes it trivial to use.
My understanding is that SpringDM is a dead project. Check the GA and release dates. So although it contributed much to the development of the specification in the end it had a bad approach to classloaders. Apache-Aries is a strong blueprint implementation. Note that use of blueprint does not preclude use of spring. I would suggest Karaf as a robust platform that can use either Eclipse Equinox or Apache Felix for the OSGI engine. I like blueprint versus DS if you are developing at the application level where your services may be used by other teams or organizations within your enterprise, or extended by your customers. I think blueprint is also a better fit for traditional enterprise computing environments. But DS or Ipojo may be more appropriate depending on your particular target environment.
In addition to what Dmytro Pishchukhin answered, it should be noted that the Spring DM project is somewhat a dead project, as DM 2 never reached a "release" version.
Instead it was contributed to the Eclipse foundation where it mutated into the Gemini Blueprint project.
In the introduction of the Gemini Blueprint documentation they explain clearly the difference :
http://www.eclipse.org/gemini/blueprint/documentation/reference/1.0.2.RELEASE/html/index.html
I reproduce here :
Chapter 1. Spring Dynamic Modules becomes Eclipse Gemini Blueprint
In late 2009, as a member of the Gemini project proposal, SpringSource contributed Spring Dynamic Modules (also known as Spring OSGi) project to the Eclipse Foundation. Spring DM v2 code base has been moved to Eclipse.org along with its issue tracker and forum. The project became dual licensed under Apache License and EPL.
While the name has changed, the code and its functionality remained the same. Existing Spring DM applications can be easily migrated to Eclipse Gemini Blueprint as mentioned in the migration guide.
Related
I'm trying to get comfortable in the vast ecosystem of enterprise OSGi programming, but I find it very difficult to get an overview of how this technology stack is put together, which technologies build upon one another, which technologies solve what task, and how they all fit in the limited terminology I have managed to understand so far.
For example: What is the relation between Apache Felix, Equinox, Karaf, Jira OSGi, Spring DM, Aries Blueprint, Gemini Blueprint, iPOJO, Camel etc. etc...
I know Equinox is based on Felix, and that the Blueprint variants and iPOJO are somewhat related to component management, but what about Declarative Services? Is DS an alternative to Blueprint, or is Blueprint an implementation of Declarative Services?
In general, I am heavily confused, and I really need a simple overview of how common OSGi technologies in general are related.
Does anyone know of there exists such an overview - perhaps graphical - of the OSGi ecosystem?
Best regards.
I don't know of a graphical representation. I can break down the few specific things you have mentioned in your post:
An "OSGi Framework" is an implementation of the core OSGi specification. It would have to implement the concept of bundles, installing and resolving bundles, lifecycle, services and so on.
Apache Felix is an OSGi Framework implementation.
Equinox is also an OSGi Framework implementation. It is not "based on" Apache Felix but it does borrow a small amount of code from it. Equinox is the implementation of OSGi used in Eclipse etc.
Karaf is essentially an application server product. It uses Felix as its core OSGi Framework implementation, and then adds a lot of extra features on the top.
Jira OSGi: don't know. I believe Jira is internally implemented with OSGi but I don't know any of the details.
Spring DM is an obsolete/dead project. It was a way of splitting up a Spring bean graph into a modular application, using OSGi.
Blueprint is a specification published by the OSGi Alliance. It is one of the Compendium specifications, i.e. add-ons that are not required in the Core. Blueprint was inspired by Spring-DM and it standardises the idea of wiring together beans within and between bundles.
Gemini Blueprint is an implementation of the Blueprint specification. Gemini started with the Spring-DM code and evolved it to comply with the (then) new specification.
Aries Blueprint is also an implementation of Blueprint. It is "clean-room", i.e. implemented from scratch against the specification rather than evolved from older Spring code.
Declarative Services is an OSGi specification from the Compendium. It is an alternative way to define components and to wire them together using services across bundles. Many experienced OSGi developers – including me – consider Declarative Services to be FAR superior to Blueprint. I can elaborate more on the reasons for that if you like.
iPOJO is yet another different way to define components and wire them together. It does not conform to any OSGi specification.
Camel is an integration library, mostly used for messaging applications. It doesn't have much to do with OSGi except that it can run under OSGi.
I hope this helps.
Actually I was reading about Spring Dynamic Modules and OSGi. All of them referenced the URL http://www.springsource.org/osgi for downloading the related libraries and jar files.
As you can verify, everytime I click on this url, it gives me the following error page:
So I was searching for an alternative and then find the manning forum which can be found here https://forums.manning.com/posts/list/25280.page
and in this forum they answered:
go to this page: http://www.springsource.org/download
Finally when I click on the last link it is being redirected to the http://spring.io/projects site, in which there is no sign of Spring DM.
My Question is How/Where can I download the latest version of Spring DM libraries?
Spring DM is discontinued for a long time now.
It is replaced by blueprint now which is an OSGi standard. There are two implementations Apache Aries Blueprint and Eclipse Gemini Blueprint.
Remember though that blueprint is not fully compatible to spring. For example you can not easily use the spring namespaces. On the other hand blueprint is much better adapted to OSGi than spring DM which causes a lot of classloading problems.
For selecting between the two implementations I suggest to go with the one that matches you runtime environment. If you plan to do server side work then you should consider Apache Karaf. It is very well integrated with Apache Aries but not so well with Gemini. On the other hand if you choose Eclipse virgo as a server then Eclipse Gemini Blueprint is the better choice.
It looks like the project was moved to Eclipse, it is now called Eclispe Gemini Blueprint (http://www.eclipse.org/gemini/blueprint/ - also has links to the Download page), I'm not so sure if that project is alive either.
From http://www.eclipse.org/gemini/blueprint/documentation/reference/1.0.2.RELEASE/html/eclipse-migration.html:
Chapter 1. Spring Dynamic Modules becomes Eclipse Gemini Blueprint
In late 2009, as a member of the Gemini project proposal, SpringSource
contributed Spring Dynamic Modules (also known as Spring OSGi) project
to the Eclipse Foundation. Spring DM v2 code base has been moved to
Eclipse.org along with its issue tracker and forum. The project became
dual licensed under Apache License and EPL. While the name has
changed, the code and its functionality remained the same. Existing
Spring DM applications can be easily migrated to Eclipse Gemini
Blueprint as mentioned in the migration guide. While the project name
has changed (to Eclipse Gemini Blueprint) and significant efforts have
been made to reflect this in the project documentation and resources,
there might be places that we have missed; if you find any, please
report them to us.
long time ago I have already been working with Spring in an OSGI context. At this time there was a subproject called Spring Dynamic Modules being the first address for an integration of the two frameworks.
Coming back to the scene some years later the situation is not clear anymore (for me). Spring Dynamic Modules has migrated to Blueprint and there are 2 major implementations Aries and Gemini where the first one seems to be more in competition with Spring than complementing it and the latter seems to be small and with very rare release cycles.
The official Spring page has no documentation at all any more concerning OSGI.
So can anyone with a better standing / know how in Spring help and tell me what's currently (11/2014) the "official" or preferred way to integrate Spring applications into an OSGI environment?
Many thanks & best regards
Rabe
Official according to whom? There is nobody qualified to give an "official" answer on this, there are only common practices.
As you note, the Eclipse Gemini implementation of Blueprint is abandonware. The Apache Aries implementation is a live project though, and it is not so much in competition with Spring as a clean-room implementation of the Blueprint specification without reference to the old Spring source code.
As such, I recommend migrating to the Aries Blueprint implementation as the most practical and sensible way forwards.
Spring does not officially support OSGi nowadays. Spring EBR repository was closed (I guess as they had said they would close it) and some company took over the content in Virgo EBR repo. I do not know if it is still alive.
If you have a choice, do not use Spring within OSGi. It is a great technology, but it was designed to work well in monoholitic systems. There is a good blog post why not to use Spring, blueprint and similar technologies within OSGi: http://blog.osgi.org/2014/09/how-should-i-use-guicespringblueprint.html
What is the status of the current developments around Spring and OSGi?
It looks like things have gotten a bit quiet lately.
The latest version of the doc at (http://docs.spring.io/osgi/) is from 2009.
I see some announcements that Spring DM has become Eclipse Gemini Blueprint (http://www.eclipse.org/gemini/blueprint/documentation/migration/). But also there, the latest release is from August 2012.
Is Spring and OSGi a dead path? If so, what other options are there to make a spring application modular (e.g. allow deployment, starting, stopping & updating of a module within a running JVM)?
Thanks
I agre that spring on OSGi is a dead end. There does not seem to be any real drive in it since springsource abandoned OSGi.
There are some alternatives though. The most stable and complete one is Apache Aries at the moment. It provides blueprint support which is similar to spring xml and some extensions like jpa container managed transactions. Be aware though that aries still contains much less functionality then spring. So for example annotation support is very limited.
Alternatives to Aries blueprint are Declarative Services and pax CDI. Declarative services is very small footprint and quite stable and has great supports for the dynamics of OSGi. On the other hand it is even more limited than blueprint. So for example there is no special jpa support at all.
PAX CDI aims to provide Java EE on OSGi using Open Webbeans or Weld + some extensions like Deltaspike. Together it would provide similar comfort like Java EE 6. Unfortunately it is not completely finished so at the moment I would not yet consider it ready for production use.
Gemini Blueprint is still active, right now gemini blueprint upgraded to support R5 and M2 is available in the eclipse nexus.
I have a Spring3 application which takes about 3 minutes to load a big domain model on startup... this is fine when the application is deployed to a production environment every once in a while but its a massive pain when making development changes due to the stopping/starting of the application.
I've done a bit of investigation and I like the idea of separating my application in modules using OSGi so that I can deploy only the parts of my application which are changing (e.g. No need to deploy the Domain Model when I'm making changes to the Persistence layer); However I've found the barrier to entry for OSGi to be quite high.
Is it possible to use both Blueprint to inject the services provided between modules (e.g to expose implementations of the domain model to my web tier) and to continue to use the Spring framework (not Spring Dynamic Modules) inside each of my modules?
You can not mix blueprint and spring. They are two separate technologies that are similar but incompatible.
I would also not recommend using spring dm in OSGi. While it works for some simple cases it has a horrible classloading model that leads to massive problems in OSGi. See this article from Guillaume Nodet. Besides that spring dm was abandoned by springsource. There are not even bug fixes since ages.
Spring Gemini is also practically abandoned. Springsource donated it to eclipse and then ceased to really work on it.
So if you want to go this step to OSGi you will have to switch to aries blueprint or to declarative services. So do not underestimate the effort.