“Eu sou parte de uma equipe.

Então, quando venço, não sou eu apenas quem vence. De certa forma, termino o trabalho de um grupo enorme de pessoas” Ayrton Senna

Nesse segundo posts sobre Corda Blockchain falaremos sobre o Gradle, uma ferramenta de automação que ajuda no gerenciamento de ciclo de vida de projetos.

Sobre como aprendo

Desculpem o vacilo e lapso mental… essa é a última parte do post que estou escrevendo, e é a mais importante, a que deu origem ao título sobre minha metodologia de aprendizado.

Basicamente o que faço é me abastecer de todo o conhecimento que tenho até o dado momento, por exemplo:

• O desafio não é com Corda e JVM? Com toda a certeza vou escolher Kotlin dado a limitação do Java 8 com Corda.
• Tem Gradle no meio? Com certeza vou aplicar a última versão do Gradle e fazer meus testes.
• As versões de dependências serão sempre as últimas a não ser que eu apanhe de alguma delas, assim aproveito e testo novas coisas…
• Posso não saber de Corda, mas Springboot, Kotlin e Gradle são obrigação…

Esses foram alguns pensamentos que pairaram minha cabeça quando iniciei o desenvolvimento… eu tinha uma zona de segurança a qual me alicerçar, a questão era então saber como aplicar Corda a todo o arcabouço de conhecimento que eu já tinha.

O que eu faço? Basicamente pego duas ideias e tento juntá-las… mais para frente falaremos que a ideia desse código entregue foi a junção do meu conhecimento de API First com esse repositório de negociações em Corda. Copio e colo de início mesmo… tento entender o porque as coisas funcionam… começo a tirar partes do código e ver se ainda sim funcionam ou o comportamento inesperado que geram… essa é basicamente a forma como aprendo algo novo.

Agora que eu já justifiquei o título da série inteira, vamos voltar à programação original…

Gradle 101 — History so far…

11 de Novembro de 2016, um commit simples, mas um marco fundamental na minha carreira:

“Atualização de arquitetura de projeto para Gradle”

Esse pequeno texto refletiria muito para mim, e olha eu escrevendo sobre ele mais de 3 anos depois… Foi um commit que removi o Maven de um projeto e apliquei o Gradle, deixando o projeto ainda funcionando.

Como a maioria dos desenvolvedores Java que conheço, iniciei minha vida utilizando o Maven. Eu ficava maravilhado com todo aquele XML que eu poderia utilizar para gerenciar meu projeto.

Na real, para a galera não vir aqui falando que eu sou “modinha”, meu ponto é basicamente o seguinte: é mais que obrigação de alguém que chega depois e, estuda os problemas que um dado player resolve, analisar os gaps e se propor a fazer melhor…

Quem fala que Maven isso ou aquilo às vezes pensa que essa história começou simplesmente do Maven e depois apareceu magicamente o Gradle, mas nossa timeline poderia ser melhor descrita assim:

• 2000 — Another Neat Tool (sim… a formiguinha (ANT) é só um acrônimo… obrigado, de nada)
• 2002 — Maven
• 2005 — Ivy
• 2007 — Gant (Sim… tentaram reviver o ANT)
• 2007 — Gradle

É muito fácil olhar para o Maven hoje e pensar que existem outras formas de fazer as coisas… é tipo aquela galera que olha para SOAP e se sente o iluminado por usar REST, como se na época em que o protocolo foi criado essa não tivesse sido uma boa aposta e que até hoje funciona.

“Ain, ele usa SOAP, que ultrapassado…”

O problema que sempre tivemos era como versionar dependências que usamos no projeto para não ficarmos com projetos grandes demais, evitar versionar libs. Além disso, como criar nossos scripts para facilitar isso…

XML tinha a vantagem de manter uma estrutura baseada em um XML Schema Definition (XSD) para a gente…

Um dos problemas é que dependendo do projeto, seu pom.xml ficava gigante…

Não consegui achar de onde peguei a imagem, mas creio que foi do próprio Gradle em uns treinamentos gratuitos deles que eu fiz, que são muito bons, diga-se de passagem.

Nesse ponto, cheguei à conclusão que a discussão entre Maven e Gradle é gosto… ainda que o Gradle tenha uma página dedicada apenas a essa comparação, outros fatores também são importantes para a decisão: profissionais que trabalham com cada uma das frentes, como definir uma arquitetura corporativa, quantidade de plugins, dentre outras…

Já conversei com arquitetos que não viam vantagem de poder programar em ferramentas de build, com o Gradle, por exemplo, é possível ter essa parte em Groovy ou Kotlin hoje.

Enfim… creio que fica muito mais como uma escolha de cada um… nesse post a ideia é mostrar as vantagens de se aplicar Gradle no nosso projeto, e como pensei para fazê-lo.

Mas Gradle não era só para Android?

Minha história com o Gradle, apesar daquele commit em código que foi para produção, começou antes, por volta de 2012/ 2013.

À época eu trabalhava em um instituto de pesquisa de Brasília, o IBTI. Lá, um desenvolvedor Android chamado Felipe Belluco uma vez veio me perguntar se eu estava a fim de conhecer “umas coisas diferenciadas”.

Uma das vantagens de um instituto de pesquisas é pesquisar, algo semelhante ao que escrevi em um post sobre Paul Arden e experimentar coisas novas.

Acabei gostando muito… falarei novamente do Sr. Belluco adiante quando formos falar sobre Lint para Kotlin, afinal, esse Sr. me apresentou Gradle e Kotlin… Um homem, uma lenda, um mito…

Respondendo a pergunta do tópico, não, Gradle pode ser utilizado em mais cenários além de Android. E mesmo para quem acha que ele está restrito à JVM, segue a seguinte informação do próprio site deles:

Write in Java, C++, Python or your language of choice. Package for deployment on any platform. Go monorepo or multi-repo. And rely on Gradle’s unparalleled versatility to build it all.

Sobre o projeto

Como dito anteriormente, o projeto que iremos discorrer nesses posts está versionado no GitHub.

Vamos falar sobre alguns pontos interessante:

Wrapper

gradlew e gradlew.bat, esses são dois caras que muitas pessoas tem em seus projetos e não sabem para que servem. Como descrito no README do nosso projeto:

O projeto foi concebido para que a instalação do Gradle fosse opcional, para tanto, é possível rodar as configurações do projeto após instalação do Java pelos arquivos gradle.bat em sistemas Windows e gradlew em sistemas Unix, que interagem com o arquivo gradle-wrapper.jar contido na pasta gradle/wrapper na raiz do projeto.

Utilizando-se Maven em projetos Springboot com o Initializr é possível chegar a um modelo semelhante.

No caso do nosso projeto, mais configurações de Wrapper podem ser encontradas dentro do arquivo build.gradle, na raiz do mesmo

ext {

  gradleWrapperVersion = "6.6.1"
}

wrapper {

  gradleVersion = "$gradleWrapperVersion"
}

É essa task que interage com a versão do Gradle do arquivo gradle-wrapper.jar contido na pasta gradle/wrapper. Atualizar a versão do Gradle do meu projeto, neste caso, nada mais é que alterar a versão da dependência no meu ext e depois interagir com a task wrapper.

Variáveis, afinal… é ou não é uma linguagem de programação?

Outra vantagem que acho bem fera no Gradle é a definição de variáveis e interação com elas:

ext {  

  cordaVersion = "4.5"
  cordaGroup = "net.corda"

  libs = [
    corda : [
      "$cordaGroup:corda-core:$cordaVersion",
      "$cordaGroup:corda-jackson:$cordaVersion",
      "$cordaGroup:corda-node-api:$cordaVersion",
      "$cordaGroup:corda-rpc:$cordaVersion"
    ]
  ]
}

dependencies {

  cordaCompile libs.corda
}

O código acima trabalha com o conceito de compilação de dependências em lote… sabe aqueles imports que você precisava escrever linhas e linhas com o mesmo groupId e version? Pois bem, essa acho uma solução bem elegante para o problema… ela é uma evolução de uma outra abordagem que eu usava antes:

ext {

  kotlinVersion = '1.3.31'

  kotlinArtifacts = [
    'kotlin-allopen',
    'kotlin-noarg',
    'kotlin-gradle-plugin'
  ]
}

dependencies {

  kotlinArtifacts.each {
    a-> classpath "org.jetbrains.kotlin:$a:$kotlinVersion"
  }
}

Nesse segundo exemplo é possível ver uma coisa bem interessante, a diferença entre aspas simples e aspas duplas para o Groovy. Resumindo-se, com aspas duplas é possível fazer interpolação de String… vocês podem ver que eu tinha paciência para fazer isso antes, separando coisas com e sem interpolação :).

Definições externas

Uma das coisas que acho mais fera no Gradle é a possibilidade de separar configurações em mais de um lugar, utilizando o princípio de Separation of Concerns e o Simple Responsability Principle.

apply from: "$rootDir/plugins/sonarqube.gradle"

configure(allprojects - project(":application")) {  

  apply from: "$rootDir/plugins/kotlin.gradle"
  apply from: "$rootDir/plugins/docs.gradle"
  apply from: "$rootDir/plugins/ides.gradle"
  apply from: "$rootDir/plugins/jacoco.gradle"
  apply from: "$rootDir/plugins/lint.gradle"
  apply from: "$rootDir/plugins/security.gradle"
}

Dentro da raiz do projeto é possível perceber a pasta plugins, lá estão definidas as configurações que estou usando referentes a SonarQube, Kotlin, documentação, IDEs, JaCoCo, Lint e Segurança.

Isso deixa meu build.gradle muito mais limpo.

A estrutura do projeto

Como dito, o Corda tem um repositório bem interessante de exemplos. Mais para frente falaremos sobre o de Kotlin em especfico; mas uma coisa que me incomodava em outros projetos que eu pegava era que a separação de projetos ficava na mesma raiz do projeto principal… falarei um pouco mais sobre isso na Parte 7: Sobre desenvolvimento em Corda.

Uma forma que o Gradle me ajudou com isso foi no arquivo settings.gradle, em que sou bem livre para definir a arquitetura que eu quero usar.

rootProject.name = "ms-cambio"

include 'application:cordapp-flows'
include 'application:cordapp-contracts-states'
include 'application:rest-api'

Eu e meu brother Igor Vieira, o Igão da massa, havíamos nos aventurado em uma jornada com Arquitetura Hexagonal em um dos nossos projetos na AIS Digital, a separação entre os projetos adapters-in, adapters-out, configuration e core foi o que me inspirou para essa organização acima.

No meu caso, não posso falar que segui premissas de uma Arquitetura Hexagonal, mas achei interessante a separação, deixando minhas camadas mais evidenciadas. Em uma solução no mundo real, talvez eu trabalhasse com mais de um repositório, um só para camada CorDapp, outro para a camada de REST API e outro para a camada de frontend… mas como dito no primeiro artigo, a separação entre REST API e CorDapp está mais para uma especulação por hora, dado eu estar ainda abstraindo os conceitos… a camada de frontend sim, certeza que seria outro repositório.

No demais é isso… nos encontraremos no próximo post em que falarei sobre README e Documentação.

E você tem alguma consideração sobre Corda, Gradle, Maven, Kotlin, Java e quer trocar uma ideia? Só bora…

Esse post faz parte de uma série sobre Corda Blockchain.

A série completa é:

• Corda Blockchain | Desafio R3 — Pensamentos sobre minha metodologia de aprender algo novo (Introdução)
• Corda Blockchain | Desafio R3 — Pensamentos sobre minha metodologia de aprender algo novo (Parte 1: Sobre Gradle)
• Corda Blockchain | Desafio R3 — Pensamentos sobre minha metodologia de aprender algo novo (Parte 2: Sobre Documentação)
• Corda Blockchain | Desafio R3 — Pensamentos sobre minha metodologia de aprender algo novo (Parte 3: Sobre Lint) [não publicado]
• Corda Blockchain | Desafio R3 — Pensamentos sobre minha metodologia de aprender algo novo (Parte 4: Sobre Versões Desatualizadas de dependências) [não publicado]
• Corda Blockchain | Desafio R3 — Pensamentos sobre minha metodologia de aprender algo novo (Parte 5: Sobre Vulnerabilidades de dependências) [não publicado]
• Corda Blockchain | Desafio R3 — Pensamentos sobre minha metodologia de aprender algo novo (Parte 6: Sobre Github flow) [não publicado]
• Corda Blockchain | Desafio R3 — Pensamentos sobre minha metodologia de aprender algo novo (Parte 7: Sobre desenvolvimento em Corda) [não publicado]
• Corda Blockchain | Desafio R3 — Pensamentos sobre minha metodologia de aprender algo novo (Parte 8: Sobre testes em Corda) [não publicado]
• Corda Blockchain | Desafio R3 — Pensamentos sobre minha metodologia de aprender algo novo (Parte 9: Sobre AssertJ) [não publicado]
• Corda Blockchain | Desafio R3 — Pensamentos sobre minha metodologia de aprender algo novo (Parte 10: Sobre testes de arquitetura) [não publicado]
• Corda Blockchain | Desafio R3 — Pensamentos sobre minha metodologia de aprender algo novo (Parte 11: Sobre testes de mutantes) [não publicado]
• Corda Blockchain | Desafio R3 — Pensamentos sobre minha metodologia de aprender algo novo (Parte 12: Sobre JaCoCo) [não publicado]
• Corda Blockchain | Desafio R3 — Pensamentos sobre minha metodologia de aprender algo novo (Parte 13: Sobre SonarQube) [não publicado]
• Corda Blockchain | Desafio R3 — Pensamentos sobre minha metodologia de aprender algo novo (Parte 14: Sobre API First e OpenAPI 3) [não publicado]
• Corda Blockchain | Desafio R3 — Pensamentos sobre minha metodologia de aprender algo novo (Parte 15: Sobre Springboot) [não publicado]
• Corda Blockchain | Desafio R3 — Pensamentos sobre minha metodologia de aprender algo novo (Parte 16: Sobre Mapstruct) [não publicado]

Esse artigo foi escrito ouvindo-se 3rd Root

Original post published at Medium on September 15th, 2020.