Corda Blockchain | Desafio R3 — Pensamentos sobre minha metodologia de aprender algo novo (Parte 1: Sobre Gradle)
Tags: corda, blockchain, jvm, gradle
Published: 2020-09-15 21:28:37

---
title: Corda Blockchain | Desafio R3 — Pensamentos sobre minha metodologia de aprender algo novo (Parte 1: Sobre Gradle)
published: true
description: Sobre experimentar com Corda Blockchain
tags: corda, blockchain, jvm, gradle
cover_image: https://media-exp1.licdn.com/dms/image/C5112AQGwT1sMc6Efpw/article-cover_image-shrink_600_2000/0?e=1605744000&v=beta&t=UR1WS3o2-rbKvoUGdipjKhR4255qVsCxaMWIpwuhaS8
---

> “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](https://www.corda.net/) falaremos sobre o [Gradle](https://gradle.org/), 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](https://github.com/arthurfnsc/openapi-apifirst) com esse [repositório de negociações em Corda](https://github.com/corda/samples-kotlin/tree/master/Advanced/negotiation-cordapp). 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](https://maven.apache.org/). Eu ficava maravilhado com todo aquele **XML** que eu poderia utilizar para gerenciar meu projeto.

![Sarcasm](https://dev-to-uploads.s3.amazonaws.com/i/7q4qb7nwicymex0yb764.jpg)

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](https://ant.apache.org/) (sim… a formiguinha (**ANT**) é só um acrônimo… obrigado, de nada)
* 2002 — [Maven](https://maven.apache.org/)
* 2005 — [Ivy](https://ant.apache.org/ivy/)
* 2007 — [Gant](https://gant.github.io/) (Sim… tentaram reviver o **ANT**)
* 2007 — [Gradle](https://gradle.com/)

É 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…”

![Mi-mi-mi](https://dev-to-uploads.s3.amazonaws.com/i/qmfcr5jt10uhoaeod7z4.jpg)

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](https://gradle.com/training/) deles que eu fiz, que **são muito bons, diga-se de passagem**.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/kjvh6eb71rmlrtw4ul1g.png)

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…

[![Gradle vs Maven Comparison | https://boaglio.com/index.php/2019/09/05/10-motivos-para-usar-maven-ou-gradle-em-seu-projeto/](https://boaglio.com/wp-content/uploads/2019/09/m2-gradle.png)](https://gradle.org/maven-vs-gradle/ "Gradle vs Maven Comparison | https://boaglio.com/index.php/2019/09/05/10-motivos-para-usar-maven-ou-gradle-em-seu-projeto/")

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](https://ibti.org.br/). Lá, um desenvolvedor Android chamado [Felipe Belluco](https://dev.to/felipebelluco) 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](https://dev.to/arthurfnsc/paul-arden-pensando-ao-contrario-parte-2-experimentando-coisas-novas-mesmo-nao-gostando-inicialmente-35kc).

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](https://gradle.org/):

> 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](https://github.com/arthurfnsc/ms-cambio).

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](https://start.spring.io/) é 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

```groovy

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:

```groovy

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:

```groovy

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](https://en.wikipedia.org/wiki/Single-responsibility_principle) e o [Simple Responsability Principle](https://en.wikipedia.org/wiki/Single-responsibility_principle).

```groovy

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](https://github.com/corda). Mais para frente falaremos sobre o de [Kotlin em especfico](https://github.com/corda/samples-kotlin); 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.

```groovy

rootProject.name = "ms-cambio"

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

```

Eu e meu brother [Igor Vieira](https://www.linkedin.com/in/igorcardosovieira/?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3BjBbKs09TT7Sau3GoZdPslw%3D%3D), o Igão da massa, havíamos nos aventurado em uma jornada com [Arquitetura Hexagonal](https://reflectoring.io/spring-hexagonal/) em um dos nossos projetos na [AIS Digital](https://www.aisdigital.com.br/), 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)](https://dev.to/arthurfnsc/corda-blockchain-desafio-r3-pensamentos-sobre-minha-metodologia-de-aprender-algo-novo-introducao-4jnb)
* 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)](https://dev.to/arthurfnsc/corda-blockchain-desafio-r3-pensamentos-sobre-minha-metodologia-de-aprender-algo-novo-parte-2-sobre-documentacao-3cj8)
* 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**

{% spotify spotify:album:04BVBQ8MSTBwkL9q3pYcZp?si=vY8fzaj9SFGzZ2kV7RKKDg %}


Original post published at [Medium](https://medium.com/@arthurfnsc/corda-blockchain-desafio-r3-pensamentos-sobre-minha-metodologia-de-aprender-algo-novo-parte-1-c7a43bfdad80) on September 15th, 2020.