Se você caiu de paraquedas aqui e não entendeu nada do assunto, calma eu vou explicar. O Spring.NET é um container IoC super robusto, mas não caiu na graça da comunidade. Uns reclamam de lentidão, outros reclamam do xml outros reclamam por ter sido inspirado no Spring do java. Eu gosto e defendo sua abordagem, o Spring.NET é alicerce das minhas arquiteturas no .NET Framework, e já faz muito tempo que sinto falta dele no .NET Standard / .NET Core. No post Spring.NET o Renascimento eu fiz um overview sobre o assunto, mas há muito mais assuntos relacionados quando olhamos para tags como Dependency Injection, DI, Inversion Of Control, IoC, e claro, não poderia faltar Spring.NET. A questão é: Agora, oficialmente, estou tocando um fork do projeto, quer participar? Fale comigo!

#spring-net/issues/133

A saga com o port do projeto começa bem antes de fazer meu primeiro port do projeto, em Setembro/2017. Eu já estava adiando alguns projetos esperando pela movimentação a respeito da issue issue #133 | .NET Core support, inclusive em no final de setembro de 2017 publiquei uma espécie de incentivo, mostrando que era possível migrar sim e que não seria algo tão complexo. A primeira decisão seria quebrar o projeto, já que migrar o Spring.Core e Spring.AOP representava um esforço muito pequeno, e daria uma boa sobrevida ao projeto. Seria aqueles 20% de esforço que geram 80% do resultado! Na prática, em menos de 12 horas era possível, para qualquer mantenedor assíduo/profundo conhecedor do projeto realizar esse refactoring. O resultado dessa empreitada foi o surgimento de uma frente de trabalho, conduzida por Jeffrey Schultz (Newport News, VA, US) mas que foi paralisado.

#spring-net/issues/144

Na issue #144 | I wish to join this project to help get it going again Jeffrey, eu, mantenedores e outros curiosos abordamos o futuro do projeto. Minha opinião é bem simplista: Migrar mais de 15 módulos é um esforço que não gera tanto resultado. Migrando os principais, seria possível reengajar a comunidade, possibilitando a chegada de sangue novo para a migração dos demais módulos. Spring.Core e Spring.AOP, alicerces do framework, poderiam ser migrados primeiro, em job de míseras 12 horas. Os demais poderiam usar o empenho da comunidade ou simplesmente serem adiados para o futuro. Isso já faria com que o projeto não morresse. O fork do Jeffrey não durou muito e já parou! 🙁

Spring.* ➡ Summer.* ➡ Oragon.Spring.*

Jocosamente batizei o primeiro fork/demo de Summer.* (Summer.Core e Summer.Aop) 😎 como um trocadilho ao Spring. Naquele momento eu queria mostrar que era possível dar um primeiro passo. Eu não estava preocupado com mais nada além de dizer: Hey guys, we can do that!

Mas o tempo foi passando, sem nenhum posicionamento definitivo, nenhuma atitude, vez ou outra aparecendo um pull request do capeta com uma bizarrice qualquer, enfim, nada aconteceu. Agora, no final de junho/2018, cansado dessa inércia, resolvi seguir em frente e tocar meu fork. Agora rebatizado de Oragon.Spring, sobre o org Oragon no github, migrei os fontes do primeiro fork criando uma baseline nova. Nesse momento assumo a briga, abraço a causa e sim temos um projeto surgindo.

Por que só agora?

Não fazia sentido criar um fork sem que houvesse divergência. Manter um projeto desses é extremamente custoso, exige cuidado, atenção, ocupação e preocupação. Pra piorar, nunca tive ambições no refactoring do projeto em si, apenas pequenas melhorias em performance, otimizações, coisas básicas. Nunca vislumbrei um roadmap para o projeto, pois nunca me senti “dono” do projeto. Agora é hora de pensar nessas coisas, e portanto, exige cuidado, carinho e uma dose de esforço, assim como um filho.

Quando um projeto morre ou sai da sua mão, é ótimo, pois o tempo que aquele projeto tomava e passa a não tomar mais, abrindo possibilidades para outros projetos ou para simplesmente não fazer nada. Os argumentos que demandaram a criação desse fork não são tão nobres, mas justificam o esforço, afinal, ao meu ver não há substituto à altura hoje. Eu esperei enquanto dava para esperar, agora, estou sentindo a dor de não ter, ao meu ver, substituto, com tais características me suportando no desenvolvimento, e estou prestes a começar alguns projetos novos dos quais preciso ter uma infraestrutura que me de suporte da forma que eu preciso.

Próximos passos

O projeto está no ar, em breve publicarei as novidades.

Ainda falta:

• Trazer a documentação
• Refatorar a documentação com base
• Fundir Spring.Core e Spring.Aop em um só [projeto|pacote|dll].
• Rever readme, licença
• Criar uma infraestrutura de integração contínua
• Achar uma forma de realizar upgrades automáticos de pacotes nuget (para achar quebras de forma proativa)

Até lá! Nos vemos nos próximos capítulos dessa novela!