SpringFramework remove metadados OSGi na migração para Gradle

A SpringSource tem sido grande defensora do Gradle, sistema de builds baseado em Groovy, e há cerca de um ano e meio começou a migração do Ant+Ivy para o Gradle. Agora que o desenvolvimento da versão 3.2 está prestes a ser finalizado, parece ser uma consequência o fim da geração de metadados OSGi para builds publicados no Maven Central.

Antes forte apoiadora do OSGi (como pode ser percebido nesta entrevista de 2008 com Rod Johnson para o InfoQ.com), a SpringSource vem gradualmente diminuindo seu suporte a OSGi e tecnologias modulares. Apesar de produtos como o Spring Roo, que roda com OSGi desde 2010, e o Spring dmServer (lançado em 2008) terem investido inicialmente no ecossistema do OSGi, más decisões de design, como a tentativa de restringir fortemente dependências por Bundle-Name e a exigência de um número de versão exato (ao invés de usar Import-Package e um intervalo de versões) prejudicaram a adoção de tecnologias modulares.

A intenção de prover multi-tenancy (múltiplos inquilinos) no Spring Dynamic Modules, devido à reescrita de nomes de pacotes e consequente quebra de imports versionados, gerou mais problemas que soluções, resultando numa adoção comercial limitada.

Em 2009, a Spring DM iniciou sua transição para a Fundação Eclipse, onde se tornou conhecido como Eclipse Virgo. Desde então, Rod Johnson mudou seu ponto de vista, argumentando que OSGi não é fácil o suficiente. A versão final de Spring com metadados OSGi foi lançada no final de 2011, e como parte da migração para o Gradle, deixou de possuir metadados OSGi. Builds até a versão 3.1 continuarão possuindo metadados OSGi, pois são geradas com Ant+Ivy. Mas esse não é o caso para novas builds baseadas na versão 3.2, apesar de existir um plugin OSGi para o Gradle que realiza trabalho semelhante ao plugin Maven Felix BND.

Rod Johnson deixou a SpringSource em julho de 2012, mas as decisões já haviam sido tomadas, e a transição do sistema de builds estava bem adiantada. Mais adiante, isso pode causar impactos no SpringSource EBR e no projeto Eclipse Virgo, pois esses projetos dependem dos metadados OSGi. No futuro, a única maneira de se obter módulos Spring compatíveis com OSGi será através do SpringSource EBR. Isso talvez não seja possível para quem estiver atrás de firewalls e quem apenas replica artefatos do repositório central do Maven.

A falta de metadados OSGi nos projetos Spring o preocupa?