BT
x Por favor preencha a pesquisa do InfoQ !

SpringFramework remove metadados OSGi na migração para Gradle

por Alex Blewitt , traduzido por Hugo Lavalle em 10 Jan 2013 |

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?

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião
Feedback geral
Bugs
Publicidade
Editorial
Marketing
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2016 C4Media Inc.
Política de privacidade
BT

Percebemos que você está utilizando um bloqueador de propagandas

Nós entendemos porquê utilizar um bloqueador de propagandas. No entanto, nós precisamos da sua ajuda para manter o InfoQ gratuito. O InfoQ não compartilhará seus dados com nenhum terceiro sem que você autorize. Procuramos trabalhar com anúncios de empresas e produtos que sejam relevantes para nossos leitores. Por favor, considere adicionar o InfoQ como uma exceção no seu bloqueador de propagandas.