BT

InfoQ Homepage News SpringFramework Removes OSGi Metadata in Move to Gradle

SpringFramework Removes OSGi Metadata in Move to Gradle

Bookmarks

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

Rate this Article

Adoption
Style

Hello stranger!

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

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Did you read the announcement?

    by Neil Bartlett /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    NuGet also has a command-line interface. NuGet FAQ

  • Re: Gradle and OSGi

    by Mark N /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 /

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

  • Re: OSGi misuse

    by Mark N /

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

  • Re: Did you read the announcement?

    by Mathilde Ffrench /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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/

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT

Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
Country/Zone:
State/Province/Region:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.