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
