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.
Related
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.
Is the any way to perform integration CQ5 platform with Spring framework?
I would like to use Spring IoC capabilities to make my code more clear and efficient.
UPDATE
Hello againg, seems that I found solution.
Guys here developed Slice framework that really redices amound of code and made CQ5 development easier.
You probably want to check out Eclipse Gemini Blueprint, or it's original incarnation Spring Dynamic Modules. The Blueprint project basically gives you an easy way to create Spring enabled bundles in an OSGi environment.
As shsteimer mentions, Spring distributions before 3.2.0 were OSGi bundles, so could be dropped into an OSGi environment and you could probably use them directly. Spring 3.2.0 bundles and above are now available through the SpringSource ERB. However, Blueprint gets around or helps with some of the boilerplate OSGi stuff that you would otherwise have to do.
On a past project, I was able to get Spring JDBC working inside of CQ (to support some legacy code so we didn't have to re-write it). My memory is that the spring jar files already come "OSGI-ified" and so it was just a matter of figuring out all the layers of dependency needed for JDBC to work inside of CQ, and adding all the jars to the repository in an /apps/myApp/install folder.
Long story short, I'm not sure about IoC, but you might check to see if it's already packaged as an OSGI version which you can simply use without too much hassle.
I seem to be really struggling here. What I want to do (in this order) is:
1) Build a RESTful resource using a Jersey application and resource w/annotations (this is not the issue).
2) Package, install, and start that bundle into the Felix OSGi container, as an HTTP service, including dependencies.
3) Package, install, and start a WAR in the OSGi container that may incorporate #2 as a dependency.
And I would like to be able to do all of this using Maven.
I cannot seem to find a working example of even the individual steps, especially involving Maven, that work let alone the combination of those steps. I have tried cobbling together various q&a from across the web with varying levels of success but not an end-to-end working example yet.
Any pointers would be appreciated...
I do not have an example for Jersey but I have a tutorial for CXF with Apache Karaf (which uses Felix). It shows how to create a Rest service and build it with maven. Using Apache Karaf you can then deploy the bundle directly from the maven repo. Moving this to Jersey probably just means to exchange the lib and use another blueprint config to initialize the rest service.
Apache Karaf also allows to deploy wars and wabs but I have not yet tested them.
Apache Stanbol does most or all of this (not sure if the war packaging is included out of the box) to implement its RESTful services.
You'll have to dig through its codebase but searching for Jax-RS annotations in there should point you to the right places.
I also am really struggling with exactly what you are attempting to do. So far, I seem to be really close but alas not quite there, here's what I've been doing:
creating a War with Maven that defines my Jersey Resource's
bundling it with maven bundle plugin ( see section Adding OSGi metadata to existing projects without changing the packaging type ). Which allows me to run the restlets in Tomcat and test.
define a target in Eclipse that includes resources from my locally defined p2 site which I create with the p2-maven-plugin plugin. In this way I can gather up any of the dependencies from the WAR project into a p2 site, which I can deploy to an Eclipse defined target
Where I am stuck is trying to register the Jersey Resource's as services, for which I've tried:
using the JAX-RS OSGI connector, for which I eventually gave up on because it uses glassfish jersey which seems to export a version 2 API of Jersey when Jersey hasn't even defined a version 2 API yet. This caused package resolution problems when I wanted to use version 1.17 of Jersey libs.
registering the Resources using a Whiteboard a la Apache Felix HTTP Service, my current approach which doesn't seem to work yet.
And, finally, if the preceding doesn't work I'll try Amdatu
Another route I might try is from the Jersey project OSGI chapter
I tried this combination and made it up and running -
1- Modularity Specification-->OSGi specification
2- OSGi implementation-->Apache Felix 4.4.0
3- OSGi Runtime-->Apache Karaf 3.0.3
4- Software Architecture Specification of REST – JAX-RS
5- JAX-RX implementation-->Apache CXF – 2.7.5
You can refer this nice tutorial - http://java.dzone.com/articles/building-cxf-rest-service-osgi
Now, I am also planning to move to Jersey from CXF as the Jersey is the light wait reference implementation of JAX-RS. Now I am planning to use Jersey with Apache Felix/Apache Karaf. You can install Jersey in Karaf and deploy your Jersey Rest Web Services as Bundle. You can refer this tutorial - https://vzurczak.wordpress.com/2014/09/30/web-applications-with-osgi-working-with-jersey/
Here's a good example on github : https://github.com/ddragosd/jax-rs-on-karaf
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.
I am about to incorporate Spring DM into a bundle that will run in the Apache Karaf OSGi framework. Given that Spring DM is being transitioned to Gemni Blueprint, should I use Spring DM 2.0.0.M1 or start fresh with Gemni Blueprint 1.0.0.M1? Or should I go with the last formal release of Spring DM (1.2.1)? Any thoughts?
UPDATE:
This could serve as an argument against using Gemni Blueprint:
As of M1, not all modules or projects
inside Spring DM have been moved. At
the moment only the io, core, extender
and test modules have transitioned are
provided in M1. With the up-coming
release of OSGi RFC-66, the web
support is being discontinued.
Existing users are encouraged to look
at Eclipse Gemini Web project. The
plans for the Maven archetype and
annotation extension are undefined for
the moment. -- http://www.eclipse.org/gemini/blueprint/documentation/migration/
The fact that not all of the Spring DM modules are included in Gemni Blueprint could make existing documentation difficult to follow. Has anyone tried using Gemni Blueprint and Gemni Web to do the same things that are done with Spring DM?
Since Spring DM has been contributed to the Eclipse Foundation more than 1.5 years ago, I suggest you to go with Gemini Blueprint:
In late 2009, Spring DM has been contributed to the Eclipse Foundation as the Gemini Blueprint project. All new development is now hosted and released through the Eclipse foundation. Please see the Gemini Blueprint site for details.
For more information on the Gemini project and Spring DM donation see the links below:
see here. Documentation for migration from Spring DM here.
Also you probably should check out Virgo.