SpringFramework Removes OSGi Metadata in Move to Gradle

by Alex Blewitt on Oct 24, 2012 |

SpringSource have been an advocate backer of the Groovy-powered Gradle build system for some time, and a year and a half ago the push began to move their build system from Ant+Ivy to Gradle. Now that the development of 3.2 is nearing completion, it appears that a casualty of that decision is to stop generating OSGi metadata for builds that get published to Maven central.

Once a keen supporter of OSGi (as seen in this 2008 interview with Rod Johnson on InfoQ), SpringSource has been gradually moving its support away from OSGi and modular technologies. Although initially products such as Spring Roo (running on OSGi in 2010) and Spring dmServer (released in 2008) invested in the OSGi ecosystem, poor design decisions such as attempting to tightly constrain dependencies by Bundle-Name and with an exact version (instead of via Import-Package and a more permissive and sensible version range) hampered the adoption of the technologies. These design failures live on in the SpringSource EBR.

A focus on providing multiple tenancy in the Spring Dynamic Modules runtime (by re-writing package names and breaking versioned imports) caused more problems than it solved, with the result that commercial adoption was limited. In 2009, Spring DM started its transition to the Eclipse Foundation where it ultimately became known as Eclipse Virgo.

Since then, Rod Johnson has changed his view, arguing in the middle of last year that OSGi is not easy enough. The final version of Spring with OSGi metadata was released at the end of last year, and as part of the move to the Gradle build system no longer contains any OSGi data. Any service builds of 3.1 will continue to have OSGi metadata, as they are built with Ant+Ivy, but new builds based on 3.2 will not be – despite Gradle providing an OSGi plugin that performs the same work as the Maven Felix BND plugin.

Although Rod Johnson left SpringSource earlier this year, the decisions and build system transition were well in place at this time. In future, this may impact the SpringSource EBR and the Eclipse Virgo project that depends on it. In the future, the only way to get OSGi-compliant Spring modules may be to go via the SpringSource EBR; something that may not be possible for those behind firewalls and who only proxy assets from the de-facto standard Maven Central.

Will the lack of OSGi metadata in all Spring projects be a concern to you? Will the wider adoption of Gradle reduce OSGi content in Maven Central? Let us know your thoughts in the comments below.

Edited on 31st October to reflect corrections provided by SpringSource; SpringFramework 3.1 is built with Ant+Ivy, not Maven

Related Editorial

Impact of Java EE Frameworks on the Structural Quality of Applications

From Killer Apps to App Killers: The Devastating Effect of Architecturally Complex Defects

Infographic: Just How Big is the Nerd Economy

Everything You Need To Know About Graph Databases – View Introductory Video

Getting Ahead in the Cloud: The Need for Better Identity and Access Controls

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

Did you read the announcement? by Neil Bartlett Posted

Re: Did you read the announcement? by Mathilde Ffrench Posted

Gradle and OSGi by Hans Dockter Posted

Re: Gradle and OSGi by Faisal Waris Posted

Re: Gradle and OSGi by Mark N Posted

Re: Gradle and OSGi by tony bargnesi Posted

Re: Gradle and OSGi by Mark N Posted

OSGi misuse by Kit Davies Posted

Re: OSGi misuse by Neil Bartlett Posted

Re: OSGi misuse by Mark N Posted

Walking away from OSGi by Ross Mason Posted

Did you read the announcement? by Neil Bartlett

It says: "SpringSource will create and publish bundles for Spring Framework 3.2 GA to the EBR in a separate process shortly following the GA release". Doesn't sound much like "abandoning OSGi" to me.

Also, VMWare just yesterday (re)joined the OSGi Alliance.

Gradle and OSGi by Hans Dockter

Why should the wider adoption of Gradle reduce the OSGi content in Maven Central? With Gradle you can publish to Maven central and generate OSGi metadata very conveniently (as you pointed out in the article). So why do you think Gradle adoption would influence OSGi content?

BTW: I don't think any build system is _the_ industry standard at the moment. For good or bad, Ant is still the most widely used build system in the Java enterprise world, followed by Maven and then already Gradle. For other widely used platforms (e.g. .NET, Javascript, C/C++, Android, iOS, Scala) things look very differently and neither Ant nor Maven do have a significant market share. Gradle will become the new standard for Android and we are also working on providing excellent solutions for the other platforms that I mentioned.

Re: Gradle and OSGi by Faisal Waris

Occasionaly I have to work with java and I find Maven to be baffling. It usually takes me a few days to sort out the dependencies.

By comparison NUGET (nuget.org/) in Visual Studio works like a charm.

Re: Gradle and OSGi by Mark N

I am not defending Maven but .... NuGet does not do the same thing as Maven.

"NuGet is a Visual Studio extension that makes it easy to install and update third-party libraries and tools in Visual Studio."

"Apache Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information." etc.

Re: Gradle and OSGi by tony bargnesi

NuGet also has a command-line interface. NuGet FAQ

Re: Gradle and OSGi by Mark N

Yeah, NuGet is moving towards being more Mavenish (I have not kept up though). But still the point is, they do not do the same thing. If they did, then NuGet would be "baffling" too. :)

Just for fun, lets look at the FAQ link:
"NuGet requires Visual Studio 2010 or Visual Web Developer Express 2010. " - Maven does not require any IDE.

"Keep in mind that the focus of NuGet is to let you modify your projects and add references to Visual Studio projects. " - That is not the focus of Maven (adding references and dependencies to your "projects").

OSGi misuse by Kit Davies

Maybe it's just me, but it does read like they didn't use OSGi properly from the outset, got stung so just walked away rather than put things right. Unfortunately, this is rather common in Java-land. There is the assumption that the OSGi fairy dust will just put everything right, but this is only true IME when best practices are strictly adhered to, and most usually on greenfield projects. Trying to wrap up existing code with OSGi is a nightmare, particularly if the components come from various sources with various degrees of commitment to modularising the code.

When it is done right, the results can be dramatic. The new WebSphere AS Liberty Profile is a rewrite of the core WAS code based around OSGi, and the differences in size and logical complexity compared to the old WAS we know and love are pretty extreme. They've recently had it running on the Raspberry Pi.

In the meantime, with a major Java thought-leader walking away from OSGi, and a further delay to Jigsaw, will Java ever "get" modularisation?

Re: OSGi misuse by Neil Bartlett

"Major Java thought-leader"? I thought we were talking about SpringSource? .... ;-)

Re: OSGi misuse by Mark N

Agree - Many times the tool is not the problem. But it still gets blamed.

Re: Did you read the announcement? by Mathilde Ffrench

is there anybody here understanding the springsource / vmware strategy about java modularity ? are they waiting jigsaw on Java 8 - uhm sorry - Java 9 ?

Walking away from OSGi by Ross Mason

I'm not going to comment on this specific article since even though SpringSource have put some distance between themselves and OSGi (rejoining the alliance doesn't really mean much, past actions such as dumping dm Server more telling) I'm not sure moving to Gradle really signifies any change in view. We (MuleSoft) went through a similar dance with OGSi and concluded at the time (2010) that it wasn't ready for wide consumption. There is a good debate on our postion here: blogs.mulesoft.org/osgi-no-thanks/