Licensing and General Strategy
As with any announcement of this magnitude, people will find both good and bad items to highlight. Phil Zoio on the Impala project (which is creating a solution similar to Spring-DM licensed under the Apache License 2.0) blog had the following to say:
...is essentially a Spring OSGi integration on steroids. I've voiced concerns on how well OSGi is going to be received by ordinary developers, as against application server vendors. I'm yet to be persuaded that regular Java developers will be particularly enthusiastic about dealing with the idiosyncracies of OSGi...there is the question of the license. For the first time, SpringSource is introducing a major product which is not based on the Apache V2.0 license, instead going for a GPL license. That's a major change that reflects a real difference in the way that the company is positioning itself in the marketplace ... Finally, the question in my mind is where the Spring Framework itself fits into all of this. I've always thought of the Spring Framework as the flagship product coming from the Rod Johnson crew. ... But with the Spring Application Framework, they're betting big...
Per Olesen on the other hand seems enthusiastic about the product and the license:
...I am already utilizing the springframework as my main engine and have long time gone the POJO ORM way. All this way before JEE5 and JPA. And I like it. I have even ditched using JEE5 EJBs on new products, because I find the spring model superior in many ways. And about it being proprietary. The platform is GPLv3 licensed, which I really like. In my eyes, the GPL license model is good for exactly this kind of product. It ensures openness, also when utilized by others, which adds or enhances it...
Billy Newport of IBM provides an appserver vendor angle:
...It looks like what others and I have been planning/hoping to do over the next few years. Most of us are looking for an OGSi based distributed platform with a commercial friendly license (EPL, BSD or Apache) ... So, to summarize, I don’t see the platform as the valuable thing. I see it as a commodity. I see profiles and monitoring profiles as the valuable thing and I’d like to see a commercial friendly licensed OSGi distributed runtime as the new JVM that vendors build middleware/profiles for. Given, Spring DM is Apache licensed, I can see the extra work in the Spring server being clean roomed and made available with EPL or Apache pretty soon and this will limit the value from selling the SpringSource server ... I don't want to trivialize what SpringSource has done, it's very cool and it's needed but given most of its components are Apache 2.0 or EPL then the last gap is a lot simpler than building a Java EE or BPEL flow engine, thats all.
IBM Fellow Jerry Cuomo also comments:
...An article on InfoQ, broke the story and my Inbox lit up like a Christmas tree. Subject lines cited – “SpringSource is declaring war on WebSphere.” Really? I don’t quite see it that way. Let me start by saying this… I’m a fan of Spring, and I think that a foundation of OSGi and technologies like Spring framework are the future of Java-based application serving. The days of one-size fits all servers are evolving towards purpose built servers that specialize in specific types of workloads ... Now, I do feel it’s a shame that SpringSource went off and did this under a GPL license. The industry would benefit from an Apache-licensed “reference” application platform ... Hence, the trend of evolving towards a platform with a right-sized, multiple personality complexion is not a disorder, nor a pending war between SpringSource and WebSphere –it is just the way the industry is evolving– and perhaps the Java community can pull together like it did before and produce a level field of opportunity. Our customers really appreciated this, the last go around...
Finally, no roundup of reactions would be complete without the musings of Marc Fleury (formerly of JBoss):
Truth is, I care a little bit but not a lot. To me this is a VC driven move. Spring is a natural consultancy, being a development framework, but they have been struggling with their sales in the runtime. So voila, we now have a box drawn around an OSGi kernel ... Finally I am fuzzy on how this impacts their relationship with other app-servers. They are not neutral anymore ... Look guys, the application server wars were fought and over by 2005. We are in 2008 with POJO programming everywhere, lite programming models in EE.
OSGi and Technical Aspects
In parallel to the expected strategic commentary, the SpringSource Application Platform announcement also generated responses from a number of developers active in the OSGi community. Neil Bartlett found a number of positives includes its general use of OSGi, the announced bundle repository, and SAP solving the where do I start with OSGi problem. He was concerned with the new bundle headers however:
...Now, here are the things I’m less than thrilled about ... There are two new bundle headers, Import-Bundle and Import-Library. As far as I can see, Import-Bundle has exactly the same problems as Require-Bundle. The new header simply provides indirection, i.e. you supply a logical bundle name rather than the actual Bundle-SymbolicName. This doesn’t fix the issues with binding to the wrapper around a set of packages rather than the packages themselves. Import-Library appears to be even worse, as it performs an Import-Bundle over a whole set of bundles at once!...
Peter Kriens had similar thoughts:
...The bundle repository was in one word: stunning. ... This bundle repository must have been a terrible job to do. Kudos! ... The Spring Source Application Platform was, however, a bit of a shock. Looking through the documentation I found lots of headers that felt like OSGi but that I did not recognize: Import-Library, Import-Bundle, Application, etc. It looked like SpringSource had “improved” OSGi extensively...
The SpringSource team also produced several blog posts detailing various aspects of the application platform:
Running Spring Applications on OSGi with the SpringSource Application Platform
- Load Time Weaving
- Classpath scanning
- Thread context classloader management
SpringSource Application Platform Deployment Options
- Raw OSGi Bundles
- Java EE WAR
- Web Modules
- Platform Archive (PAR)
SpringSource Application Platform Manifest Headers
- Import-Bundle
- Import-Library
Working with SpringSource Application Platform's provisioning repository
- Runtime provisioning
- Adding items to the provisioning repository
- Sharing the provisioning repository between installations
One of the main advantages of the SpringSource Application Platform is its ability to provision dependencies on an as-needed basis. The benefits of this are two-fold: it ensures that the Platform's memory footprint is as small as possible and it allows applications to be deployed without encapsulating all of their dependencies in a monolithic deployment unit, e.g. a WAR file. To take advantage of these capabilities you will require an understanding of the Platform's provisioning repository and this blog intends to provide just that...