DEV Community: Arthur Fonseca

Cursos que formaram meu caráter: Desenvolvimento web com Quarkus - Validação de vulnerabilidades com OWASP Dependency Check

Arthur Fonseca — Sun, 18 Dec 2022 03:05:26 +0000

"Mais visibilidade é mais poder, mas mais vulnerabilidade". Ezra Furman

Nesse sétimo post falaremos sobre vulnerabilidades em bibliotecas. Se você trabalha com Java há algum tempo, creio que a vulnerabilidade do log4j possa ter te dado algumas dores de cabeça.

Como desenvolvedores, um ponto que falaremos é o que fazer quando descobrirmos um vulnerabilidade. Lembre-se que:

"Para todo problema complexo existe sempre uma solução simples, elegante e completamente errada". H L Mencken

Esse artigo faz parte de uma série, abaixo é possível encontrar a lista completa de artigos.

Estamos nos baseando no curso Desenvolvimento web com Quarkus do @viniciusfcf.

O repositório que estamos utilizando é:

udemy / Desenvolvimento Web com Quarkus / ifood · GitLab

GitLab.com

gitlab.com

Vulnerabilidades

Em TI temos uma máxima de que não existe sistema perfeito! Mesmo soluções que funcionam sem nenhum problema aparente podem apresentar problemas desconhecidos ou novos problemas dado a evolução de outras bibliotecas ou mesmo outros problemas.

O cenário do Log4J aconteceu recentemente, e o pessoal do Coffee and IT até fez um vídeo explicando com um viés de desenvolvimento.

Algumas perguntas podem ficar em nossas cabeça:

Como saber mais sobre vulnerabilidades de bibliotecas?
O que fazer quando descobrir uma vulnerabilidade em meu código?
Será que consigo automatizar de alguma forma a descoberta dessas vulnerabilidades?
Dentre outras

OWASP e CVE

Um dos pontos de início pode ser a OWASP (The Open Web Application Security Project).

owasp.org

A OWASP é uma fundação sem fins lucrativos que trabalha para melhorar a segurança do software. Eles possuem Chapters em vários países, bem como realizam uma série de eventos com esse foco.

Uma de suas publicações mais conhecidas é o OWASP Top Ten em que são documentadas as 10 maiores vulnerabilidades dados um período de tempo.

owasp.org

Outro termo que falaremos também é o CVE (Common Vulnerabilities and Exposures). No Maven Repo é bem comum ver uma observação quando estamos buscando uma biblioteca.

Note que a versão 2.15.0.Final do Quarkus JUnit 5 nos apresenta alguns alertas:

Olhando um pouco mais para as versões do quarkus-junit5 podemos ver que para a versão 2 do Quarkus ainda não temos nenhuma correção para essas vulnerabilidades.

Estou vulnerável, e agora?

New Blood Showtime GIF by Dexter - Find & Share on GIPHY

Discover & share this Dexter GIF with everyone you know. GIPHY is how you search, share, discover, and create GIFs.

giphy.com

Um insight legal que recomendo a todos desenvolvedores é: converse com pessoas de outras áreas para formar uma opinião.

Como desenvolvedores é bem comum acharmos vulnerabilidades e já pensarmos em subir novas versões ou já colocar a mão no código.

Há uns anos atrás tive uma conversa com o Bruno Almeida na ília Digital; ele por ter um background em segurança me fez exatamente essa pergunta, questionando sobre o que eu faria.

Falei que iria atualizar as bibliotecas, alterar o código e coisas do tipo.

Ele então me trouxe um outro ponto de vista bem interessante: Será que preciso atualizar o código? Será que a vulnerabilidade que tenho é passível de ser explorada? Algumas vezes trabalhamos com APIs e diversas camadas como microservices, API Gateway dentre outras, e pode ser que uma fez configurado algo em uma camada superior, não seja passível de se explorar a vulnerabilidade.

O ponto então que ficou em minha mente foi: é importante descobrir as vulnerabilidades que estamos expostos, em seguida entender se essas vulnerabilidades são passíveis de serem exploradas, e caso sejam passíveis de serem exploradas, analisar o impacto de correção nos pontos de nossa solução em que tal vulnerabilidade pode ser explorada.

Automatizando a descoberta de possíveis vulnerabilidades

A OWASP tem um projeto bem interessante, o Dependency-Check.

owasp.org

Ele possui uma série de plugins e integrações que podemos usar para descobrir CVEs no nosso projeto.

No arquivo build.gradle do nosso projeto podemos ver a primeira parte da configuração do plugin:

plugins {
    ...
    id "org.owasp.dependencycheck" version "$dependencyCheckVersion" apply false
}

...

subprojects {
    if (it.name != 'applications') {
        ...
        apply from: "$rootDir/plugins/security.gradle"
    }
}

E no arquivo plugins/security.gradle podemos ver a segunda parte da configuração:

apply plugin: "org.owasp.dependencycheck"

dependencyCheck {
    autoUpdate = true
    format = "ALL"
    outputDirectory = "build/reports/dependencyCheck"
}

Para a lista de demais configurações, acesse o link.

A task que iremos utilizar para executar o plugin será a dependencyCheckAnalyze

Essa task busca as vulnerabilidades associadas a nossas dependências e nos da um detalhamento.

Abrindo o arquivo dependency-check-report.html temos o seguinte:

Além de informar as bibliotecas que temos vulnerabilidades, o plugin consegue obter mais detalhes sobre o problema, situações em que ele acontece e às vezes até direcionamentos sobre a solução. No caso da venerabilidade no okhttp-3.14.9.jar temos:

In verifyHostName of OkHostnameVerifier.java, there is a possible way to accept a certificate for the wrong domain due to improperly used crypto. This could lead to remote information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-8.1 Android-9 Android-10 Android-11Android ID: A-171980069

Integração com SonarQube

Outra coisa que podemos fazer é instalar o plugin no nosso SonarQube e assim termos uma rastreabilidade de vulnerabilidades como parte do nosso relatório do projeto.

dependency-check / dependency-check-sonar-plugin

Integrates Dependency-Check reports into SonarQube

Dependency-Check Plugin for SonarQube 8.x and 9.x

Integrates Dependency-Check reports into SonarQube v8.9 or higher.

The project will try to backport all code from master branch to last supported LTS. Please see the SonarQube 6.x or SonarQube 7.x branch for old supported version.

About Dependency-Check

Dependency-Check is a utility that attempts to detect publicly disclosed vulnerabilities contained within project dependencies. It does this by determining if there is a Common Platform Enumeration (CPE) identifier for a given dependency. If found, it will generate a report linking to the associated CVE entries.

Dependency-Check supports the identification of project dependencies in a number of different languages including Java, .NET, Node.js, Ruby, and Python.

Note

This SonarQube plugin does not perform analysis, rather, it reads existing Dependency-Check reports. Use one of the other available methods to scan project dependencies and generate the necessary JSON report which can then be consumed by this…

View on GitHub

Ignorando falsos positivos

É possível ainda ignorar falsos positivos através da configuração suppressionFile.

jeremylong.github.io

Conclusão

O OWASP Dependency Check é um plugin fantástico que pode nos ajudar na descoberta de vulnerabilidades em nossos projetos. Uma consideração é avaliarmos o impacto de tais vulnerabilidades em nossos códigos, além do custo de correção caso seja o nosso caso.

No próximo post falaremos do último plugin utilizado no projeto. Ele será bem importante para formatação do nosso código Groovy, Java, SQL, dentre outros.

Esse post faz parte de uma série sobre Cursos que formaram meu caráter: Desenvolvimento web com Quarkus.

A série completa é:

Talk is cheap show me the code
Utilizando Gradle ao invés de Maven
Plugins do Gradle: Gerenciador de versões de bibliotecas com Versions
Plugins do Gradle: Saudades do Maven, relatórios com Project-report
Plugins do Gradle: API First com o OpenAPI Generator
Plugins do Gradle: API First com o OpenAPI Generator para APIs reativas
Plugins do Gradle: Validação de vulnerabilidades de dependências com OWASP Dependency Check
Plugins do Gradle: Lint com Spotless [não publicado]
GitLab: Motivação para a escolha [não publicado]
GitLab: Considerações sobre o Prettier em pipelines [não publicado]
Gitmoji [não publicado]
SDK Man [não publicado]
Pré commit hook [não publicado]
application.yml: Utilizando YML em propriedades de aplicação [não publicado]
application.yml: Utilizando variáveis de ambiente [não publicado]
application.yml: Sobrescrevendo opções em teste [não publicado]
Mapstruct: Utilizando expressões para mapeamentos [não publicado]
Microprofile SecurityScheme: Sobrescrevendo tokenUrl [não publicado]
Prometheus: O problema simples que me custou algumas horas [não publicado]
quarkus-hibernate-reactive-panache: Utilizando as vantagens do Hibernate em projetos reativos [não publicado]
Testcontainers: Configuração para projetos reativos [não publicado]

Cursos que formaram meu caráter: Desenvolvimento web com Quarkus - API First com o OpenAPI Generator para APIs reativas

Arthur Fonseca — Sat, 17 Dec 2022 21:12:42 +0000

"Todo ato de criação é, antes de tudo, um ato de destruição" Pablo Picasso

Neste sexto post falaremos sobre geração de APIs reativas.

Esse artigo faz parte de uma série, abaixo é possível encontrar a lista completa de artigos.

Estamos nos baseando no curso Desenvolvimento web com Quarkus do @viniciusfcf.

O repositório que estamos utilizando é:

udemy / Desenvolvimento Web com Quarkus / ifood · GitLab

GitLab.com

gitlab.com

OpenAPI Generator e APIs reativas

O segundo módulo ministrado por Vinícius nos apresenta problemas que a solução está mais alinhada com assincronismo.

Como estava seguindo a abordagem de API First com OpenAPI Generator para endpoints REST fui procurar se existia alguma forma de se fazer isso com o plugin.

Vi que a abordagem que estávamos utilizando era o Mutiny, e acabei caindo nessa issue que tbredzin abriu um Pull Request:

Add support for asynchronous API for JavaJaxRsSpec #10919

tbredzin posted on Nov 21, 2021

resolves #4832 This PR is an attempt at addressing https://github.com/OpenAPITools/openapi-generator/issues/4832

Motivation

Since version 2.1, JAX-RS server side component has support for returning a CompletionStage to mark the request as eligible for asynchronous processing. The advantage this approach has over the AsyncResponse based API is that it is richer and allows you to create asynchronous pipelines.

It is also extended by 3rd party libraries such as Reactor, RxJava or Mutiny. All of those allow to convert from/to CompletionStage, examples:

Reactor:

CompletionStage<String> single = Mono.just("something").toFuture();
CompletionStage<List<String>> many = Flux.just("something", "somethingelse")
                .collectList()
                .toFuture()

RxJava3

CompletionStage<String> single = Maybe.just("something").toCompletionStage();
CompletionStage<List<String>> many = Flowable.fromArray("something", "somethingelse")
                .toList()
                .toCompletionStage();

Mutiny

CompletionStage<String> single = Uni.createFrom().item("something").subscribeAsCompletionStage();
CompletionStage<List<String> many = Multi.createFrom().items("something", "somethingelse")
                .collect()
                .asList()
                .subscribeAsCompletionStage();

Code changes

This PR adds the option supportAsync to the Java JAX-RS spec generator and updates the mustache templates.

When set to true, the generated API interfaces and classes will return CompletionStage to support running asynchronous operation in JAX-RS (supported since JAX-RS 2.1).

This option also enables java8 mode as CompletionStage requires a JDK > 1.8

Tests

Unit Tested for:

Generation with interfaceOnly=true with the petstore.yaml file
Generation with interfaceOnly=true for complex types with the ping.yaml file
Generation with interfaceOnly=true for primitive types with the issue_4832.yaml file
Generation with interfaceOnly=true and returnResponse=true with the ping.yaml file
Generation with interfaceOnly=false classes with ping.yaml

Sample of generated API interfaces (interfaceOnly=true):

//PingApi.java w/  returnResponse=true
CompletionStage<Response> pingGet();

// PetApi.java w/ returnResponse=false
CompletionStage<Pet> getPetById(@PathParam("petId") @ApiParam("ID of pet to return") Long petId);
CompletionStage<List<Pet>> findPetsByStatus(@QueryParam("status") @NotNull  @ApiParam("Status values that need to be considered for filter")  List<String> status);

//FakeApi.java
CompletionStage<Boolean> getBool(); //primitive type converted to class

// StoreApi.java
CompletionStage<Map<String, Integer>> getInventory();
CompletionStage<Order> placeOrder(@Valid @NotNull Order order);
CompletionStage<Void> deleteOrder(@PathParam("orderId") @ApiParam("ID of the order that needs to be deleted") String orderId);

Sample of generated API class (interfaceOnly=false):

public CompletionStage<Response> pingGet() {
    return CompletableFuture.supplyAsync(() -> Response.ok().entity("magic!").build());
}

Note that the current implementation from master, always returns Response. So no specific types are returned with supportAsync=true too: CompletionStage<Response>.

Project generated from it was compile successfully after running:

$ java -jar modules/openapi-generator-cli/target/openapi-generator-cli.jar generate \
-i https://raw.githubusercontent.com/OpenAPITools/openapi-generator/master/modules/openapi-generator/src/test/resources/3_0/petstore.yaml \
-g jaxrs-spec -p interfaceOnly=true,supportAsync=true -o ~/tmp

$ cd ~/tmp 
$ mvn clean package

PR checklist

[x] Read the contribution guidelines.
[x] Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
[x] Run the following to build the project and update samples:
```
./mvnw clean package 
./bin/generate-samples.sh
./bin/utils/export_docs_generators.sh
```
Commit all changed files. This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master. These must match the expectations made by your contribution. You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*. For Windows users, please run the script in Git BASH.
[x] File the PR against the correct branch: master (5.3.0), 6.0.x
[x] If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request. @nmuesch

View on GitHub

Since version 2.1, JAX-RS server side component has support for returning a CompletionStage to mark the request as eligible for asynchronous processing. The advantage this approach has over the AsyncResponse based API is that it is richer and allows you to create asynchronous pipelines.

It is also extended by 3rd party libraries such as Reactor, RxJava or Mutiny. All of those allow to convert from/to CompletionStage, examples:

Reactor

CompletionStage<String> single = Mono.just("something").toFuture();
CompletionStage<List<String>> many = Flux.just("something", "somethingelse")
                .collectList()
                .toFuture()

RxJava3

CompletionStage<String> single = Maybe.just("something").toCompletionStage();
CompletionStage<List<String>> many = Flowable.fromArray("something", "somethingelse")
                .toList()
                .toCompletionStage();

Mutiny

CompletionStage<String> single = Uni.createFrom().item("something").subscribeAsCompletionStage();
CompletionStage<List<String> many = Multi.createFrom().items("something", "somethingelse")
                .collect()
                .asList()
                .subscribeAsCompletionStage();

Pensei, porque não? Vamos ver no que isso vai dar...

Podemos ver a configuração utilizando API-First em nosso projeto nos arquivos applications/marketplace/build.gradle:

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

E no arquivo plugins/openapigen_marketplace.gradle:

import org.openapitools.generator.gradle.plugin.tasks.GenerateTask

buildscript {
    repositories {
        mavenLocal()
        maven { url "https://repo1.maven.org/maven2" }
    }
    dependencies {
        classpath "org.openapitools:openapi-generator-gradle-plugin:$openApiGenVersion"
    }
}

apply plugin: 'org.openapi.generator'

def apiServerOutput = "$buildDir/generated/openapi-code-server".toString()

task generatePratosApiServer(type: GenerateTask) {
    generatorName = "jaxrs-spec"
    inputSpec = "$projectDir/src/main/resources/openapi/pratos_v1.yml".toString()
    outputDir = apiServerOutput
    apiPackage = "org.openapi.server.v1.pratos.api"
    invokerPackage = "org.openapi.v1.pratos.invoker"
    modelPackage = "org.openapi.v1.pratos.model"
    configOptions = [
        "dateLibrary"            : "java8",
        "hideGenerationTimestamp": "true",
        "interfaceOnly"          : "true",
        "supportAsync"           : "true",
        "useOptional"            : "true",
        "useBeanValidation"      : "false",
        "useSwaggerAnnotations"  : "false"
    ]
}

task generateRestaurantesApiServer(type: GenerateTask) {
    generatorName = "jaxrs-spec"
    inputSpec = "$projectDir/src/main/resources/openapi/restaurantes_v1.yml".toString()
    outputDir = apiServerOutput
    apiPackage = "org.openapi.server.v1.restaurantes.api"
    invokerPackage = "org.openapi.v1.restaurantes.invoker"
    modelPackage = "org.openapi.v1.restaurantes.model"
    configOptions = [
        "dateLibrary"            : "java8",
        "hideGenerationTimestamp": "true",
        "interfaceOnly"          : "true",
        "supportAsync"           : "true",
        "useOptional"            : "true",
        "useBeanValidation"      : "false",
        "useSwaggerAnnotations"  : "false"
    ]
}

compileJava.dependsOn(
    generatePratosApiServer, generateRestaurantesApiServer
)

sourceSets.main.java.srcDir "$apiServerOutput/src/gen/java"

No post anterior explicamos várias dessas configurações, o que ficou faltando foi só a supportAsync que como o próprio nome já diz, habilita ou não o suporte a APIs assíncronas.

Nesse projeto também optei por criar 2 APIs para a geração, uma para pratos ("$projectDir/src/main/resources/openapi/pratos_v1.yml".toString()) e outra para restaurantes ("$projectDir/src/main/resources/openapi/restaurantes_v1.yml".toString()).

Quando executamos a fase compileJava ou tasks que dependem dela podemos ver que a seguinte estrutura foi criada em applications/marketplace/build:

Analisando as classes geradas, temos PratoAPI:

package org.openapi.server.v1.pratos.api;

import org.openapi.v1.pratos.model.Prato;
import javax.ws.rs.*;
import javax.ws.rs.core.Response;
import java.util.concurrent.CompletionStage;
import java.util.concurrent.CompletableFuture;
import java.io.InputStream;
import java.util.Map;
import java.util.List;

@Path("/pratos")
@javax.annotation.Generated(value = "org.openapitools.codegen.languages.JavaJAXRSSpecServerCodegen")
public interface PratosApi {

    @GET
    @Produces({ "application/json" })
    CompletionStage<List<Prato>> recuperaPratosRestaurante();
}

E RestaurantesAPI:

package org.openapi.server.v1.restaurantes.api;

import org.openapi.v1.restaurantes.model.Prato;
import javax.ws.rs.*;
import javax.ws.rs.core.Response;
import java.util.concurrent.CompletionStage;
import java.util.concurrent.CompletableFuture;
import java.io.InputStream;
import java.util.Map;
import java.util.List;


@Path("/restaurantes/{idRestaurante}/pratos")
@javax.annotation.Generated(value = "org.openapitools.codegen.languages.JavaJAXRSSpecServerCodegen")
public interface RestaurantesApi {

    @GET
    @Produces({ "application/json" })
    CompletionStage<List<Prato>> recuperaPratosRestaurante(@PathParam("idRestaurante") Long idRestaurante);
}

E seguindo com a nossa configuração, precisamos implementar um classe concreta para definir como o método vai funcionar:

applications/marketplace/src/main/java/com/gitlab/arthurfnsc/ifood/marketplace/PratoResource:

package com.gitlab.arthurfnsc.ifood.marketplace;

import io.smallrye.mutiny.Multi;
import java.util.List;
import java.util.concurrent.CompletionStage;
import javax.ws.rs.Consumes;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;
import org.openapi.server.v1.pratos.api.PratosApi;
import org.openapi.v1.pratos.model.Prato;

@Path("/pratos")
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
public class PratoResource implements PratosApi {

    @Override
    public CompletionStage<List<Prato>> recuperaPratosRestaurante() {
        Multi<Prato> pratos = com.gitlab.arthurfnsc.ifood.marketplace.Prato.recuperaPratosApi();
        return pratos.collect().asList().subscribeAsCompletionStage();
    }
}

applications/marketplace/src/main/java/com/gitlab/arthurfnsc/ifood/marketplace/RestauranteResource:

package com.gitlab.arthurfnsc.ifood.marketplace;

import io.smallrye.mutiny.Multi;
import java.util.List;
import java.util.concurrent.CompletionStage;
import javax.ws.rs.Consumes;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;
import org.openapi.server.v1.restaurantes.api.RestaurantesApi;

@Path("/restaurantes")
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
public class RestauranteResource implements RestaurantesApi {

    @Override
    public CompletionStage<List<org.openapi.v1.restaurantes.model.Prato>> recuperaPratosRestaurante(
        Long idRestaurante
    ) {
        Multi<org.openapi.v1.restaurantes.model.Prato> pratos = com.gitlab.arthurfnsc.ifood.marketplace.Prato.recuperaPratosApi(
            idRestaurante
        );
        return pratos.collect().asList().subscribeAsCompletionStage();
    }
}

Na classe Prato, no mesmo pacote do nosso resource implementamos os seguintes métodos:

package com.gitlab.arthurfnsc.ifood.marketplace;

...

public class Prato extends PanacheEntityBase {

    ...
    public static Multi<org.openapi.v1.pratos.model.Prato> recuperaPratosApi() {
        return findAll()
            .stream()
            .map(p -> (Prato) p)
            .onItem()
            .transform(PratoMapper::paraPratoApi);
    }

    public static Multi<org.openapi.v1.restaurantes.model.Prato> recuperaPratosApi(
        Long idRestaurante
    ) {
        return find("restaurante.id", idRestaurante)
            .stream()
            .map(p -> (Prato) p)
            .onItem()
            .transform(PratoMapper::paraPratoRestauranteApi);
    }
    ...
}

Essa minha abordagem de ter 2 OpenAPIs gerou um problema que pode ser percebido no código acima. Vocês podem percebem que acabaram sendo geradas 2 classes Prato, uma em org.openapi.v1.pratos.model.Prato e outra em org.openapi.v1.restaurantes.model.Prato o que me deixou 2 métodos muito parecidos, com uma diferença do método de transformação chamado.

No caso da solução do Vinícius as Resources dele retornam Multi:

package com.github.viniciusfcf.ifood.mp;

...
import io.smallrye.mutiny.Multi;

public class PratoResource {

    @Inject
    PgPool pgPool;

    @GET
    @APIResponse(responseCode = "200", content = @Content(schema = @Schema(type = SchemaType.ARRAY, implementation = PratoDTO.class)))
    public Multi<PratoDTO> buscarPratos() {
        return Prato.findAll(pgPool);
    }
}

package com.github.viniciusfcf.ifood.mp;

...
import io.smallrye.mutiny.Multi;

public class RestauranteResource {

    @Inject
    PgPool client;

    @GET
    @Path("{idRestaurante}/pratos")
    public Multi<PratoDTO> buscarPratos(@PathParam("idRestaurante") Long idRestaurante) {
        return Prato.findAll(client, idRestaurante);
    }
}

Como estamos trabalhando com CompletionStage ao invés de Multi, vamos ver se aquela dica do tbredzin funciona:

PratoResource

    @Override
    public CompletionStage<List<Prato>> recuperaPratosRestaurante() {
        Multi<Prato> pratos = com.gitlab.arthurfnsc.ifood.marketplace.Prato.recuperaPratosApi();
        return pratos
            .collect()
            .asList()
            .subscribeAsCompletionStage();
    }

RestauranteResource

    @Override
    public CompletionStage<List<org.openapi.v1.restaurantes.model.Prato>> recuperaPratosRestaurante(
        Long idRestaurante
    ) {
        Multi<org.openapi.v1.restaurantes.model.Prato> pratos = com.gitlab.arthurfnsc.ifood.marketplace.Prato.recuperaPratosApi(
            idRestaurante
        );
        return pratos
            .collect()
            .asList()
            .subscribeAsCompletionStage();
    }

Happy Celebration GIF by Manchester United - Find & Share on GIPHY

Discover & share this Manchester United GIF with everyone you know. GIPHY is how you search, share, discover, and create GIFs.

giphy.com

Você pode ter percebido que não interagimos com o PgPool como o Vinícius. Isso se deve ao fato de conseguirmos usar o hibernate em uma solução reativa, o que ainda estava em fase beta quando o Vinícius fez o curso dele. Falaremos mais sobre o quarkus-hibernate-reactive-panache adiante.

Considerações finais

Quando estava fazendo essa abordagem fiquei com dúvida se essa era uma boa implementação. Afinal, qual a diferença entre um Multi ou Uni e um CompletionStage? O seguinte link me ajudou um pouco a entender que eles não são a mesma coisa:

smallrye.io

While CompletionStage and CompletableFuture are close to Uni in terms of use case, there are some fundamental differences.

CompletionStage are eager. When a method returns a CompletionStage, the operation has already been triggered. The outcome is used to complete the returned CompletionStage. On the other side, Unis are lazy. The operation is only triggered once there is a subscription.

CompletionStage caches the outcome. So, once received, you can retrieve the result. Every retrieval will get the same result. With Uni, every subscription has the opportunity to re-trigger the operation and gets a different result.

Segue também um outro link bem interessante:

smallrye.io

Sobre a utilização de OpenAPI Gen para APIs reativas

Bem, essa foi a primeira implementação que fiz, e portanto não consegui abstrair maiores problemas. Como não estressei a solução em vários projetos, não seria algo que eu colocaria em produção em um cliente. Ao meu modo de ver, é importante validar outros cenários mais complexos.

Mas achei bem interessante essa possibilidade do plugin.

No próximo post falaremos sobre uma solução da OWASP para validação de vulnerabilidade em nossas bibliotecas.

Esse post faz parte de uma série sobre Cursos que formaram meu caráter: Desenvolvimento web com Quarkus.

A série completa é:

Talk is cheap show me the code
Utilizando Gradle ao invés de Maven
Plugins do Gradle: Gerenciador de versões de bibliotecas com Versions
Plugins do Gradle: Saudades do Maven, relatórios com Project-report
Plugins do Gradle: API First com o OpenAPI Generator
Plugins do Gradle: API First com o OpenAPI Generator para APIs reativas
Plugins do Gradle: Validação de vulnerabilidades de dependências com OWASP Dependency Check
Plugins do Gradle: Lint com Spotless [não publicado]
GitLab: Motivação para a escolha [não publicado]
GitLab: Considerações sobre o Prettier em pipelines [não publicado]
Gitmoji [não publicado]
SDK Man [não publicado]
Pré commit hook [não publicado]
application.yml: Utilizando YML em propriedades de aplicação [não publicado]
application.yml: Utilizando variáveis de ambiente [não publicado]
application.yml: Sobrescrevendo opções em teste [não publicado]
Mapstruct: Utilizando expressões para mapeamentos [não publicado]
Microprofile SecurityScheme: Sobrescrevendo tokenUrl [não publicado]
Prometheus: O problema simples que me custou algumas horas [não publicado]
quarkus-hibernate-reactive-panache: Utilizando as vantagens do Hibernate em projetos reativos [não publicado]
Testcontainers: Configuração para projetos reativos [não publicado]

Cursos que formaram meu caráter: Desenvolvimento web com Quarkus - API First com o OpenAPI Generator

Arthur Fonseca — Thu, 15 Dec 2022 04:53:30 +0000

"Imaginação é o começo da criação. Você imagina o que deseja, deseja o que imagina e, por fim, cria o que deseja". George Bernard Shaw

Neste quinto post falaremos sobre um tema que estudo desde 2012 quando tive uma grande experiência com SOA (Service Oriented Architecture).

Falaremos sobre pontos positivos e negativos da abordagem, uma vez que tudo tem trade-offs.

Para trabalhar com Quarkus vamos precisar usar o JAX-RS como ponte para geração de nossos contratos. Como grande fã do Spring vamos entrar em algumas discussões sobre estar ou não atrelado à especificação do Java. Vamos então comparar vantagens e desvantagens de se utilizar o JAX-RS ou abstrações Spring.

Seth Meyers GIF by Late Night with Seth Meyers - Find & Share on GIPHY

Discover & share this Seth Meyers GIF by Late Night with Seth Meyers with everyone you know. GIPHY is how you search, share, discover, and create GIFs.

giphy.com

Prefiro a solução com Spring. E irei explicar o porque.

Esse artigo faz parte de uma série, abaixo é possível encontrar a lista completa de artigos.

Estamos nos baseando no curso Desenvolvimento web com Quarkus do @viniciusfcf.

O repositório que estamos utilizando é:

udemy / Desenvolvimento Web com Quarkus / ifood · GitLab

GitLab.com

gitlab.com

SOA so far

Caso você tenha interesse em outros posts sobre SOA, escrevi alguns insights que podem ser úteis:

Em 2012 entrei em um instituto de pesquisas, o IBTI. Um instituto que foi bem importante para as minhas concepções arquiteturais.

Entrei em um laboratório de SOA e me lembro de pensar que se tratava de um plugin do Java na época.

SOA me influenciou tanto que um de seus princípios, a Padronização de contrato de serviços acabou me atrasando a entrar no mundo REST. Para mim, se eu não utilizasse Contract-First não estava bom.

Me lembro inclusive de um projeto que escrevi uma vez, que eu tinha definido um projeto multi módulo em que um módulo trabalhava com REST e esse chamava outro módulo que trabalhava com SOAP só porque eu utilizava Contract First lá.

Fico pensando hoje no overhead dessa decisão arquitetural.

São coisas que olho para trás e apesar de não concordar hoje, sei que me ajudaram a chegar aonde estou hoje.

Como dito anteriormente, em um instituto de pesquisas o que é necessário fazer é experimentar novas coisas. E experimentar quer dizer provar coisas que você não sabe se estão certas ou não.

OpenAPI abordagens

Partirei do pré-suposto que você já ouviu falar sobre OpenAPI ou Swagger daqui para frente.

Como abordagens de APIs com Swagger ou OpenAPI podemos dividir em 3 abordagens:

Escrita de contrato e implementação em uma linguagem de programação

Nesse abordagem é definido um contrato e a equipe de desenvolvimento segue a especificação em seu código de uma forma de-para.

Geração de contrato a partir de código

Nessa abordagem iniciamos por nosso código para gerar o nosso contrato.

Geração de código a partir de contrato

Nessa abordagem iniciamos por nosso contrato para a geração de um código. Essa abordagem é conhecida como Contract-First.

Prós e contra de cada abordagem

Na primeira abordagem o principal problema que possuímos é o fato de a implementação ser manual, sendo assim, o programador pode se confundir ou esquecer de algo da especificação.

Na segunda abordagem o principal problema no caso do Java são questões com a serialização e desserialização de classes que especificamos. Podemos utilizar classes que não implementam serialização para gerar nosso Swagger ou OpenAPI.

Ainda na segunda abordagem, a vantagem está em não estarmos atrelados a outras soluções e utilizar implementações que a maioria da comunidade utiliza.

Na terceira abordagem o principal problema é estar atrelado a alguma solução, que pode não ter todas as funcionalidades que precisamos.

Ainda na terceira abordagem, a vantagem é estarmos sempre alinhados a um contrato especificado, evitando a quebra o mesmo.

Nesse post iremos utilizar a terceira abordagem, mesmo tendo o problema de estar atrelado a uma solução de geração de código.

Já escrevi sobre o OpenAPI Generator, porém, precisei fazer alguns ajustes para trabalhar com isso no Quarkus e é sobre isso que vamos iniciar agora.

Mais à frente falaremos sobre outros problemas dessa abordagem.

Principais configuração em nosso projeto

Podemos ver a configuração utilizando API-First em nosso projeto nos arquivos applications/cadastro/build.gradle:

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

E no arquivo plugins/openapigen_cadastro.gradle:

import org.openapitools.generator.gradle.plugin.tasks.GenerateTask

buildscript {
    repositories {
        mavenLocal()
        maven { url "https://repo1.maven.org/maven2" }
    }
    dependencies {
        classpath "org.openapitools:openapi-generator-gradle-plugin:$openApiGenVersion"
    }
}

apply plugin: 'org.openapi.generator'

def apiServerOutput = "$buildDir/generated/openapi-code-server".toString()

task generateApiServer(type: GenerateTask) {
    generatorName = "jaxrs-spec"
    inputSpec = "$projectDir/src/main/resources/openapi/restaurantes_v1.yml".toString()
    outputDir = apiServerOutput
    apiPackage = "org.openapi.server.v1.restaurantes.api"
    invokerPackage = "org.openapi.v1.restaurantes.invoker"
    modelPackage = "org.openapi.v1.restaurantes.model"
    configOptions = [
        "dateLibrary"            : "java8",
        "hideGenerationTimestamp": "true",
        "interfaceOnly"          : "true",
        "performBeanValidation"  : "true",
        "returnResponse"         : "true",
        "serializableModel"      : "true",
        "useBeanValidation"      : "true",
        "useOptional"            : "true",
        "useSwaggerAnnotations"  : "false"
    ]
}

compileJava.dependsOn(
    generateApiServer
)

sourceSets.main.java.srcDir "$apiServerOutput/src/gen/java"

Na configuração apiServerOutput definimos um destino para no qual serão criadas nossas classes com base em nossa OpenAPI.

Na configuração do plugin definimos que utilizaremos o JAX-RS como especificação de nossa API. Lembrando que existem outras abordagens para o generatorName tanto para server quanto para client.

Na configuração inputSpec utilizamos o caminho para nossa OpenAPI no projeto.

apiPackage, invokerPackage e modelPackage são as configurações de nossos packages da aplicação que será gerada:

Sobre as configurações utilizadas em configOptions do jaxrs-spec podemos encontrar mais detalhes no seguinte link.

Definimos então as bibliotecas do java8 para configuração de nossas bibliotecas de data. Não se confunda com o fato de o Java possuir outras versões para além do 8! Para o plugin isso se refere ao fato de usarmos LocalDate, classe que apareceu a partir do Java 8.

hideGenerationTimestamp diz respeito à geração do timestamp de geração estar na interface gerada. Como estamos gerando nossas classes no package build essa é uma configuração que não impacta muito na forma como usamos o plugin.

interfaceOnly diz respeito à geração de interfaces para serem implementadas.

Para nossa abordagem não precisaremos de classes concretas, porque iremos implementar a interface, mas para entender o que mudaria no caso desse parâmetro ser false, pense nos projetos gerados a partir do site https://editor.swagger.io/ > Generate Server > jaxrs-spec. Nesse caso será criado uma classe concreta para ser evoluída.

Para entender nossa abordagem, estamos gerando uma interface Java com base em um contrato OpenAPI, essas classes geradas não precisarão ser versionadas, pois podem ser criadas e recriadas dado evolução da nossa API. O que buscamos é ter a certeza que estamos implementando todos os métodos da interface, e caso mudemos nossa OpenAPI perceber que precisamos estar em compliance com o contrato descrito.

A configuração performBeanValidation e useBeanValidation dizem respeito a utilizar o Bean Validation ou não nas classes geradas, bem como realizar sua validação em camada de Controller. Isso inclusive diz respeito a uma diferença da abordagem do @viniciusfcf. Estamos delegando ao plugin essa validação, porém isso nos trás um problema, não estamos mais controlando o Validation das nossas classes, e com isso estamos atrelados aos lados bons e ruins do plugin. Na solução utilizada pelo Vinícius, ele conseguia ajustar coisas em seus DTOs, no nosso caso estamos delegando isso às classes de modelo geradas pelo plugin. Existem até formas de sobrescrevermos como o plugin gera as classes com o Mustache, mas para fins desse post não pensei em criar configurações próprias, preferi utilizar a geradas pelo próprio plugin.

A configuração returnResponse é uma das principais reclamações que tenho com relação ao JAX-RS. Caso essa solução seja definida como false os métodos gerados terão em sua assinatura as classes da especificação e não a classe javax.ws.rs.core.Response. As vantagens do returnResponse false é a geração de métodos como:

@Path("/restaurantes")
@javax.annotation.Generated(value = "org.openapitools.codegen.languages.JavaJAXRSSpecServerCodegen")
public interface RestaurantesApi {

...

@POST
    @Consumes({ "application/json" })
    void cadastraRestaurante(@Valid CadastroRestaurante cadastroRestaurante);

@GET
    @Path("/{idRestaurante}/pratos")
    @Produces({ "application/json" })
    List<Prato> recuperaPratosRestaurante(@PathParam("idRestaurante") Long idRestaurante);

...
}

Os primeiros "problemas" com OpenAPI e JAX-RS

A desvantagem inicial que vi foi no retorno de HTTP Status para 201 Created, pois no caso de métodos de retorno void eu não consegui alterar o HTTP Status, o retorno era sempre 200 Ok. Até vi uma outra abordagem, mas para isso, porém, eu precisaria ajustar a forma como o gerador de código funciona com o Mustache para a adição do parâmetro HttpServletResponse response nos métodos gerados como mostrado por Pierre Henry nessa dúvida do Stack Overflow.

@Path("/")
@POST
@Consumes({ MediaType.APPLICATION_JSON })
@Produces({ MediaType.APPLICATION_JSON })
public User addUser(User user, @Context final HttpServletResponse response){

    User newUser = ...

    //set HTTP code to "201 Created"
    response.setStatus(HttpServletResponse.SC_CREATED);
    try {
        response.flushBuffer();
    }catch(Exception e){}

    return newUser;
}

Jan 14 '11 Comments: 3 Answers: 14

287

I'm writing a REST web app (NetBeans 6.9, JAX-RS, TopLink Essentials) and trying to return JSON and HTTP status code. I have code ready and working that returns JSON when the HTTP GET method is called from the client. Essentially:

@Path("get/id")
@GET
@Produces("application/json")
public M_機械 getMachineToUpdate(@PathParam("id") String id) {

    //

…

Open Full Question

Por outro lado, utilizar a opção returnResponse como true o retorno é a classe javax.ws.rs.core.Response, o problema é que diferente da solução do Spring o Response do JAX-RS não utiliza generics. Observe a diferença do JAX-RS e do Spring para o mesmo problema:

import javax.ws.rs.core.Response;

public interface RestaurantesApi {

    @PUT
    @Path("/{idRestaurante}/pratos/{idPrato}")
    @Consumes({ "application/json" })
    Response atualizaPratoRestaurante(
        @PathParam("idPrato") Long idPrato,
        @PathParam("idRestaurante") Long idRestaurante,
        @Valid AtualizacaoPrato atualizacaoPrato
    );

    @GET
    @Path("/{idRestaurante}/pratos")
    @Produces({ "application/json" })
    Response recuperaPratosRestaurante(@PathParam("idRestaurante") Long idRestaurante);
}


import org.springframework.http.ResponseEntity;

public interface RestaurantesApi {

    default ResponseEntity<Void> atualizaPratoRestaurante(
        @Parameter(name = "idPrato", description = "", required = true) @PathVariable("idPrato") Long idPrato,
        @Parameter(name = "idRestaurante", description = "", required = true) @PathVariable("idRestaurante") Long idRestaurante,
        @Parameter(name = "AtualizacaoPrato", description = "") @Valid @RequestBody(required = false) AtualizacaoPrato atualizacaoPrato
    ) {
        return new ResponseEntity<>(HttpStatus.NOT_IMPLEMENTED);

    }

    default ResponseEntity<List<Prato>> recuperaPratosRestaurante(
        @Parameter(name = "idRestaurante", description = "", required = true) @PathVariable("idRestaurante") Long idRestaurante
    ) {
        getRequest().ifPresent(request -> {
            for (MediaType mediaType: MediaType.parseMediaTypes(request.getHeader("Accept"))) {
                if (mediaType.isCompatibleWith(MediaType.valueOf("application/json"))) {
                    String exampleString = "{ \"preco\" : 6.027456183070403, \"nome\" : \"nome\", \"id\" : 0, \"descricao\" : \"descricao\" }";
                    ApiUtil.setExampleResponse(request, "application/json", exampleString);
                    break;
                }
            }
        });
        return new ResponseEntity<>(HttpStatus.NOT_IMPLEMENTED);

    }
}

Observe que ResponseEntity do Spring utiliza generics e Response do JAX-RS não. Com isso, acho a solução do Spring para o problema muito mais elegante, pois garanto o tipo de entidade do retorno, diferente da opção Response em que poderíamos alterar o objeto de retorno sem que houvesse um erro de compilação.

O código utilizado como referência se encontra em applications/cadastro/src/main/java/com/gitlab/arthurfnsc/ifood/cadastro/RestauranteResource:

    @Override
    @Counted(name = "Quantidade buscas restaurante")
    @SimplyTimed(name = "Tempo simples de busca")
    @Timed(name = "Tempo completo de busca")
    public Response recuperaPratosRestaurante(Long idRestaurante) {
        Optional<Restaurante> restauranteOp = Restaurante.findByIdOptional(
            idRestaurante
        );
        if (restauranteOp.isEmpty()) {
            throw new NotFoundException("Restaurante não existe");
        }
        List<Prato> pratos = Prato.list("restaurante", restauranteOp.get());
        return Response.ok(pratoMapper.paraListaPratoApi(pratos)).build();
    }

No exemplo acima, poderíamos colocar qualquer coisa dentro de Response.ok(), porém, isso não geraria erro de compilação:

    @Override
    @Counted(name = "Quantidade buscas restaurante")
    @SimplyTimed(name = "Tempo simples de busca")
    @Timed(name = "Tempo completo de busca")
    public Response recuperaPratosRestaurante(Long idRestaurante) {
        return Response.ok(LocalDate.now()).build();
    }

Lembrando que analisando friamente esse é um problema decorrente da minha escolha arquitetural. O Vinícius não teve esse problema na resolução dele.

Mais "problemas" com OpenAPI e JAX-RS

Outro problema que encontrei foi com anotações do Swagger.

Observe uma classe gerada em um projeto SpringBoot:

import io.swagger.v3.oas.annotations.Operation;
import io.swagger.v3.oas.annotations.Parameter;
import io.swagger.v3.oas.annotations.responses.ApiResponse;
import io.swagger.v3.oas.annotations.security.SecurityRequirement;
import javax.validation.Valid;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.ResponseBody;

public interface RestaurantesApi {

    @Operation(
        operationId = "atualizaPratoRestaurante",
        tags = { "prato", "restaurante" },
        responses = {
            @ApiResponse(responseCode = "204", description = "No Content")
        },
        security = {
            @SecurityRequirement(name = "ifood_auth", scopes={ "write:restaurantes" })
        }
    )
    @RequestMapping(
        method = RequestMethod.PUT,
        value = "/restaurantes/{idRestaurante}/pratos/{idPrato}",
        consumes = { "application/json" }
    )
    default ResponseEntity<Void> atualizaPratoRestaurante(
        @Parameter(name = "idPrato", description = "", required = true) @PathVariable("idPrato") Long idPrato,
        @Parameter(name = "idRestaurante", description = "", required = true) @PathVariable("idRestaurante") Long idRestaurante,
        @Parameter(name = "AtualizacaoPrato", description = "") @Valid @RequestBody(required = false) AtualizacaoPrato atualizacaoPrato
    ) {
        return new ResponseEntity<>(HttpStatus.NOT_IMPLEMENTED);

    }
}

Nessa abordagem vemos que é documentado o Request e Response do nosso método em nossa interface. Temos um "problema" com o JAX-RS, o Swagger não faz parte da especificação do Java, e precisaríamos utilizar o Microprofile para isso.

Quarkus, Swagger Ignore method/Class #22429

CormegaGit posted on Dec 21, 2021

Describe the bug

Hello,

I have a Quarkus app and i am using Swagger interface for those REST API, and all my methods are visible, i want to ignore some of them to dot be visible when i am using quarkus and i have tried like below, and also added some other @ApiOperation and so one,

When i am using Swagger all my methods are visible on Swagger interface so i dont know how to ignore some of them.

@GET @Produces(MediaType.TEXT_PLAIN) @Operation(hidden = true) @Schema(hidden=true) public TemplateInstance getGetSMTest(@QueryParam("name") String name){ LOG.info("called page /getSMTest"); return getSMTest.data("name", name); }

Best Regards, Daniel Sanchi

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

No response

Output of `uname -a` or `ver`

No response

Output of `java -version`

No response

GraalVM version (if different from Java)

No response

Quarkus version or git rev

No response

Build tool (ie. output of `mvnw --version` or `gradlew --version`)

No response

Additional information

No response

View on GitHub

"Yes, we are based on microprofile open API and does not support swagger. You can remove the swagger dependency from your classpath", phillip-kruger

Até vi a issue 795 aberta no OpenAPIGen.

Além de duas abordagens, uma com o Apache Geronimo:

Oct 10 '19 Comments: 1 Answers: 1

prior to using Eclipse Microprofile we've generated our open-api files via the io.openapitools.swagger:swagger-maven-plugin This plugin relies on the io.swagger.core.v3:swagger-annotations maven dependency.

Eclipse Microprofile though comes with a different dependency which does not seem to be enough for the openapitools plugin, therfore the generated open-api file does not contain any…

Open Full Question

E outra com o MicroGen:

MicroGen | An OpenAPI Spec Generator for Eclipse JakartaEE + Eclipse MicroProfile

An OpenAPI Spec Generator for Eclipse JakartaEE + Eclipse MicroProfile

microgen.io

Mas não cheguei a testar nenhuma das duas.

Na abordagem que estamos seguindo, para minha filosofia a escrita de org.eclipse.microprofile.openapi.annotations.responses.APIResponseSchema ou org.eclipse.microprofile.openapi.annotations.tags.Tag na nossa classe de Resource configura uma intervenção manual que pode levar a algum problema futuro se eu esquecer de evoluir esse métodos. Por isso, eu optei por não realizar tal configuração.

Por esse motivo também desabilitei a configuração useSwaggerAnnotations, uma vez que não são as anotações que desejamos expor.

Lembrando que com relação os problemas que eu levantei estão atrelados a decisões arquiteturais que eu decidi seguir. O Response do JAX-RS é um que acho que poderia ser melhorado, mas os demais estão mais atrelados à minha escolha pelo OpenAPI Generation.

Demais configurações

As próximas configurações do plugin dizem respeito ao vínculo da geração de código à task de compilação de Java, bem como colocar as classes geradas no nosso sourceSet.

compileJava.dependsOn(
    generateApiServer
)

sourceSets.main.java.srcDir "$apiServerOutput/src/gen/java"

Uma vez que essas configurações estejam definidas basta executar a task generateApiServer ou mesmo a task compileJava ou mesmo alguma que dependa dela, como build, test.

Com isso, nossas classes serão geradas em "$buildDir/generated/openapi-code-server".toString() com base no OpenAPI definido em applications/cadastro/src/main/resources/openapi/restaurantes_v1.yml.

Na nossa classe de Resource applications/cadastro/src/main/java/com/gitlab/arthurfnsc/ifood/cadastro/RestauranteResource implentamos a interface gerada:

import org.openapi.server.v1.restaurantes.api.RestaurantesApi;

public class RestauranteResource implements RestaurantesApi {

}

Isso já será o suficiente para recebermos um erro de compilação, pois precisamos implementar os métodos da interface que estamos implementando.

Essa é uma das vantagens do conceito de API First! Imagine que adicionemos outros métodos em nossa OpenAPI ou que removamos um método ou que adicionemos mais parâmetros em um método. Quando executarmos a task de geração de código receberemos erro de compilação, seja por métodos que removemos, seja por métodos que precisamos adicionar ou adicionar parâmetros.

Conclusão e observações da decisão arquitetural

Offer Decide GIF by ABC Network - Find & Share on GIPHY

Discover & share this Offer Decide GIF by ABC Network with everyone you know. GIPHY is how you search, share, discover, and create GIFs.

giphy.com

A escolha arquitetural da utilização de API First com Open API Generator nos trouxe alguns benefícios como:

Acoplamento com o contrato de serviço e suas evoluções.
Facilidade na descoberta de quebra de contrato de APIs definidas.

Porém, também nos trouxe alguns desafios que não foram passados pelo @viniciusfcf dado o fato de outra abordagem arquitetural:

Liberdade de implementação de endpoints
Gerador do JAX-RS não estar 100% alinhado com nossas expectativas.

Para além disso, gostaria de trazer mais alguns pontos que já testei com a abordagem e coisas que percebi que ela não resolve:

OpenAPI Generator sempre vai estar defasado com relação à especificação

Um ponto interessante para gerar uma discussão sobre o OpenAPI Generator é que ele invariavelmente vai estar defasado com relação ao número de features da própria especificação OpenAPI, afinal, quando uma abordagem como essa é criada, o foco inicial é na resolução dos problemas mais comuns e não de todos os problemas.

Pegue por exemplo uma coisa bem bacana do OpenAPI 3, a reutilização de responses com component responses. O código a seguir está na seção Reusing Responses:

/users:
    get:
      summary: Gets a list of users.
      response:
        '200':
          description: OK
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ArrayOfUsers'
        '401':
          $ref: '#/components/responses/Unauthorized'   # <-----
  /users/{id}:
    get:
      summary: Gets a user by ID.
      response:
        '200':
          description: OK
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/User'
        '401':
          $ref: '#/components/responses/Unauthorized'   # <-----
        '404':
          $ref: '#/components/responses/NotFound'       # <-----
# Descriptions of common components
components:
  responses:
    NotFound:
      description: The specified resource was not found
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/Error'
    Unauthorized:
      description: Unauthorized
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/Error'
  schemas:
    # Schema for error response body
    Error:
      type: object
      properties:
        code:
          type: string
        message:
          type: string
      required:
        - code
        - message

Veja que dessa forma podemos reusar as seguintes especificações:

        '401':
          $ref: '#/components/responses/Unauthorized'
        '404':
          $ref: '#/components/responses/NotFound'

Isso tornaria nossa especificação mais enxuta. Há alguns anos atrás quando testei isso não funcionava com o gerador. Testando hoje, vi que funciona, porém, é bem comum ver pontos de melhoria e adequação solicitados nas issues do projeto.

Invariavelmente ficamos atrelados ao gerador para o bem ou para o mal.

OpenAPI Generator definitivamente não combina com Serverless

Se você clonou o projeto e importou em sua IDE, provavelmente percebeu vários erros decorrentes das classes que precisam ser geradas para que sejam encontradas. Por isso colocamos o seguinte código na nossa configuração.

compileJava.dependsOn(
    generateApiServer
)

Se por um acaso você leu o README e foi executar o projeto, percebeu o seguinte output:

./gradlew clean :applications:cadastro:quarkusDev
################################################################################
# Thanks for using OpenAPI Generator.                                          #
# Please consider donation to help us maintain this project 🙏                 #
# https://opencollective.com/openapi_generator/donate                          #
################################################################################
Successfully generated code to /home/arthurfnsc/repos/udemy/ifood/applications/cadastro/build/generated/openapi-code-server
Listening for transport dt_socket at address: 5005

Note que para executar o projeto do zero precisamos criar algumas classes: Successfully generated code to /home/arthurfnsc/repos/udemy/ifood/applications/cadastro/build/generated/openapi-code-server.

No exemplo acima, imagine que o nosso projeto AWS Lambda Function utilize essa estratégia. Iremos perder um tempo para executar a requisição porque vamos precisar gerar código antes. E, mesmo depois disso, se nossa Lambda entrar em um contexto de inativação, será necessário gerar novamente código, onerando o processo.

No demais, lembrem-se, não existe bala de prata!

No próximo post falaremos da abordagem de API First em projetos de APIs reativas

Esse post faz parte de uma série sobre Cursos que formaram meu caráter: Desenvolvimento web com Quarkus.

A série completa é:

Talk is cheap show me the code
Utilizando Gradle ao invés de Maven
Plugins do Gradle: Gerenciador de versões de bibliotecas com Versions
Plugins do Gradle: Saudades do Maven, relatórios com Project-report
Plugins do Gradle: API First com o OpenAPI Generator
Plugins do Gradle: API First com o OpenAPI Generator para APIs reativas
Plugins do Gradle: Validação de vulnerabilidades de dependências com OWASP Dependency Check
Plugins do Gradle: Lint com Spotless [não publicado]
GitLab: Motivação para a escolha [não publicado]
GitLab: Considerações sobre o Prettier em pipelines [não publicado]
Gitmoji [não publicado]
SDK Man [não publicado]
Pré commit hook [não publicado]
application.yml: Utilizando YML em propriedades de aplicação [não publicado]
application.yml: Utilizando variáveis de ambiente [não publicado]
application.yml: Sobrescrevendo opções em teste [não publicado]
Mapstruct: Utilizando expressões para mapeamentos [não publicado]
Microprofile SecurityScheme: Sobrescrevendo tokenUrl [não publicado]
Prometheus: O problema simples que me custou algumas horas [não publicado]
quarkus-hibernate-reactive-panache: Utilizando as vantagens do Hibernate em projetos reativos [não publicado]
Testcontainers: Configuração para projetos reativos [não publicado]

Cursos que formaram meu caráter: Desenvolvimento web com Quarkus - Saudades do Maven, relatórios com Project-report

Arthur Fonseca — Wed, 14 Dec 2022 20:42:10 +0000

"Um site ruim é como um vendedor rabugento". Jakob Nielsen

Nesse quarto posts falaremos sobre um ponto que não gera muito impacto no projeto, mas que eu acho mais elegante a opção com Maven.

O ponto é como trazer diferentes perspectivas sobre o nosso projeto em um único lugar (o que não consegui com o Gradle).

Esse artigo faz parte de uma série, abaixo é possível encontrar a lista completa de artigos.

Estamos nos baseando no curso Desenvolvimento web com Quarkus do @viniciusfcf.

O repositório que estamos utilizando é:

udemy / Desenvolvimento Web com Quarkus / ifood · GitLab

GitLab.com

gitlab.com

Tradeoffs

sad bart simpson GIF - Find & Share on GIPHY

Discover & share this sad bart simpson GIF with everyone you know. GIPHY is how you search, share, discover, and create GIFs.

giphy.com

Sabe aquela conversa que o "nosso produto é melhor que o do concorrente em todos os aspectos"? Pois bem...

Brincadeiras à parte, o objetivo desse post está mais em enaltecer uma abordagem do Maven pouco utilizada para documentação.

É sr Tim eu sei como você se sente:

May 21 '15 Comments: 1 Answers: 2

Is there a plugin in gradle which can generate maven site similar thing? It would be great if it was compatible with current maven site apt format file.

Open Full Question

Mas o que afinal de contas o Maven Site faz?

Maven Site Plugin é um plugin que cria relatórios do projeto. Um ponto interessante é que mais do que criar os relatórios do plugin, também é possível integrar com relatórios de Testes, Versão de dependências, dentre outros.

Peguemos por exemplo o código do JUnit 4, com o código escrito no pom.xml é possível chegar ao seguinte resultado:

junit.org

Observem as informações que são possível de serem documentadas, como informações sobre configuração da biblioteca, licença do projeto, desenvolvedores, dentre outras.

Pela nostalgia voltei até aquele projeto que eu tinha falado no post sobre a mudança de Maven para Gradle e voltando para a configuração do Maven, rodei o famoso:

foo@bar:~$ ./mvnw site

Alguns reports interessantes são os de versão de dependências e plugins, que ficam mais bonitos que os nossos usando o Gradle Plugin Version.

Mas e com o Gradle?

Bom... como nem tudo são flores, o que consegui com o Gradle foi o plugin Project-Report:

docs.gradle.org

A configuração dele está no build.gradle:

subprojects {
    if (it.name != 'applications') {
        ...
        apply from: "$rootDir/plugins/docs.gradle"
    }
}

e em plugins/docs.gradle:

...
apply plugin: "project-report"

...

htmlDependencyReport {
    projects = project.allprojects
}

Com ele, podemos executar a task dependencyReport, que gerará um report dentro da pasta build de cada subprojeto nosso como o seguinte:


------------------------------------------------------------
Project ':applications:cadastro'
------------------------------------------------------------

annotationProcessor - Annotation processors and their dependencies for source set 'main'.
+--- org.mapstruct:mapstruct-processor:1.5.3.Final
\--- io.quarkus:quarkus-panache-common:2.14.3.Final
     +--- io.quarkus:quarkus-core:2.14.3.Final
     |    +--- jakarta.annotation:jakarta.annotation-api:1.3.5
     |    +--- jakarta.enterprise:jakarta.enterprise.cdi-api:2.0.2
     |    |    +--- jakarta.el:jakarta.el-api:3.0.3
     |    |    +--- jakarta.interceptor:jakarta.interceptor-api:1.2.5
     |    |    |    +--- jakarta.annotation:jakarta.annotation-api:1.3.5
     |    |    |    \--- jakarta.ejb:jakarta.ejb-api:3.2.6
     |    |    |         \--- jakarta.transaction:jakarta.transaction-api:1.3.2 -> 1.3.3
     |    |    \--- jakarta.inject:jakarta.inject-api:1.0
     |    +--- jakarta.inject:jakarta.inject-api:1.0
     |    +--- io.quarkus:quarkus-ide-launcher:2.14.3.Final
     |    +--- io.quarkus:quarkus-development-mode-spi:2.14.3.Final
     |    +--- io.smallrye.config:smallrye-config:2.12.1
     |    |    +--- io.smallrye.config:smallrye-config-core:2.12.1
     |    |    |    +--- org.eclipse.microprofile.config:microprofile-config-api:2.0.1
     |    |    |    +--- io.smallrye.common:smallrye-common-annotation:1.13.1
     |    |    |    +--- io.smallrye.common:smallrye-common-expression:1.13.1
     |    |    |    |    +--- io.smallrye.common:smallrye-common-function:1.13.1
     |    |    |    |    |    \--- io.smallrye.common:smallrye-common-constraint:1.13.1
     |    |    |    |    |         \--- org.jboss.logging:jboss-logging:3.4.3.Final -> 3.5.0.Final
     |    |    |    |    \--- org.jboss.logging:jboss-logging:3.4.3.Final -> 3.5.0.Final
     |    |    |    +--- io.smallrye.common:smallrye-common-constraint:1.13.1 (*)
     |    |    |    +--- io.smallrye.common:smallrye-common-classloader:1.13.1
     |    |    |    +--- org.jboss.logging:jboss-logging:3.4.3.Final -> 3.5.0.Final
     |    |    |    +--- org.ow2.asm:asm:9.3
     |    |    |    \--- io.smallrye.config:smallrye-config-common:2.12.1
     |    |    |         +--- org.eclipse.microprofile.config:microprofile-config-api:2.0.1
     |    |    |         +--- io.smallrye.common:smallrye-common-classloader:1.13.1
     |    |    |         \--- org.jboss.logging:jboss-logging:3.4.3.Final -> 3.5.0.Final
     |    |    \--- org.jboss.logging:jboss-logging:3.4.3.Final -> 3.5.0.Final
     |    +--- org.jboss.logging:jboss-logging:3.5.0.Final
     |    +--- org.jboss.logmanager:jboss-logmanager-embedded:1.0.11
     |    |    \--- org.wildfly.common:wildfly-common:1.5.0.Final-format-001 -> 1.5.4.Final-format-001
     |    +--- org.jboss.logging:jboss-logging-annotations:2.2.1.Final
     |    +--- org.jboss.threads:jboss-threads:3.4.3.Final
     |    |    +--- org.jboss.logging:jboss-logging:3.4.1.Final -> 3.5.0.Final
     |    |    \--- org.wildfly.common:wildfly-common:1.5.0.Final -> 1.5.4.Final-format-001
     |    +--- org.slf4j:slf4j-api:1.7.36
     |    +--- org.jboss.slf4j:slf4j-jboss-logmanager:1.2.0.Final
     |    +--- org.graalvm.sdk:graal-sdk:22.3.0
     |    +--- org.wildfly.common:wildfly-common:1.5.4.Final-format-001
     |    +--- io.quarkus:quarkus-bootstrap-runner:2.14.3.Final
     |    |    +--- io.smallrye.common:smallrye-common-io:1.13.2
     |    |    +--- org.jboss.logmanager:jboss-logmanager-embedded:1.0.11 (*)
     |    |    +--- org.jboss.logging:jboss-logging:3.5.0.Final
     |    |    \--- io.github.crac:org-crac:0.1.1
     |    \--- io.quarkus:quarkus-fs-util:0.0.9

O report é bem maior que isso, dado o número de dependências que temos, cortei para não ficar tão grande.

Temos a task htmlDependencyReport que gera um report em HTML dentro da pasta build de cada subprojeto nosso como o seguinte:

Um ponto que precisei alterar no nosso projeto foi a configuração org.gradle.jvmargs=-Xmx4096m em gradle.properties.

./gradlew clean htmlDependencyReport

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':applications:cadastro:htmlDependencyReport'.
> Java heap space

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 16s

Antes eu estava recebendo problemas de heap space no Java, para isso, aumentei a quantidade de RAM que o Gradle pode usar, como mencionado aqui:

Jul 25 '20 Comments: 3 Answers: 4

I am getting gradle build error while running the app. I am using windows 10 with 8GB RAM, Android studio version 4.0.1

Out of memory: Java heap space. Please assign more memory to Gradle in the project's gradle.properties file. For example, the following line in the gradle.properties file, sets the…

Open Full Question

Conclusão

É... não tem nem como comparar a robustez e relatórios da solução com Maven, ainda que o Maven Site precise dar um tapa na parte de UI e UX, ainda sim os insights e relatórios que podemos disponibilizar são bem interessantes.

Para quem usa o Gradle e conhecer algum outro plugin para a mesma finalidade, sou todo ouvidos.

Esse post faz parte de uma série sobre Cursos que formaram meu caráter: Desenvolvimento web com Quarkus.

A série completa é:

Talk is cheap show me the code
Utilizando Gradle ao invés de Maven
Plugins do Gradle: Gerenciador de versões de bibliotecas com Versions
Plugins do Gradle: Saudades do Maven, relatórios com Project-report
Plugins do Gradle: API First com o OpenAPI Generator
Plugins do Gradle: API First com o OpenAPI Generator para APIs reativas
Plugins do Gradle: Validação de vulnerabilidades de dependências com OWASP Dependency Check
Plugins do Gradle: Lint com Spotless [não publicado]
GitLab: Motivação para a escolha [não publicado]
GitLab: Considerações sobre o Prettier em pipelines [não publicado]
Gitmoji [não publicado]
SDK Man [não publicado]
Pré commit hook [não publicado]
application.yml: Utilizando YML em propriedades de aplicação [não publicado]
application.yml: Utilizando variáveis de ambiente [não publicado]
application.yml: Sobrescrevendo opções em teste [não publicado]
Mapstruct: Utilizando expressões para mapeamentos [não publicado]
Microprofile SecurityScheme: Sobrescrevendo tokenUrl [não publicado]
Prometheus: O problema simples que me custou algumas horas [não publicado]
quarkus-hibernate-reactive-panache: Utilizando as vantagens do Hibernate em projetos reativos [não publicado]
Testcontainers: Configuração para projetos reativos [não publicado]

Cursos que formaram meu caráter: Desenvolvimento web com Quarkus - Gerenciador de versões de bibliotecas com Versions

Arthur Fonseca — Wed, 14 Dec 2022 03:16:01 +0000

"Você torna o mundo um lugar melhor fazendo melhorias diárias para se tornar a melhor versão de si mesmo". Roy T. Bennett, The Light in the Heart

Nesse terceiro posts falaremos sobre o gerenciamento de versões utilizando o Gradle Versions Plugin do Ben Manes. Isso nos ajudará a manter nosso projeto com as dependências atualizadas.

Discutiremos também os problemas que isso pode causar, e o porque não termos um fluxo de Continuous Integration pode nos dar grandes dores de cabeça.

Por fim, falarei do Dependabot. Não apliquei nesse projeto, mas vou colocar no backlog, e quem sabe escrever em um outro post.

Esse artigo faz parte de uma série, abaixo é possível encontrar a lista completa de artigos.

Estamos nos baseando no curso Desenvolvimento web com Quarkus do @viniciusfcf.

O repositório que estamos utilizando é:

udemy / Desenvolvimento Web com Quarkus / ifood · GitLab

GitLab.com

gitlab.com

O tempo passa, o tempo voa

O tempo é implacável! Mudanças acontecem constantemente, e isso impacta decisões passadas que tomamos.

No mundo do desenvolvimento de software essa máxima permanece! Bibliotecas e frameworks são atualizados ou descontinuados; outras vezes podemos descobrir uma vulnerabilidade nas nossas dependências e sermos forçados a realizar mudanças (falaremos um pouco disso em um post futuro chamado Plugins do Gradle: Validação de vulnerabilidades de dependências com OWASP Dependency Check).

Uma das primeiras ideias que temos é: Vamos deixar o nosso projeto sempre com a última versão das bibliotecas disponíveis!

"Para todo problema complexo existe sempre uma solução simples, elegante e completamente errada". H L Mencken

Qual é o problema podemos ter nessa primeira abordagem?

Para atualizar uma dependência em um projeto é importante termos algumas coisas em mente, como:

Existe uma equipe de sustentação que precisa garantir que as bibliotecas que estamos usando estão em conformidade com uma arquitetura corporativa?
As bibliotecas que estamos usando funcionam corretamente se todas forem atualizadas para sua última versão?
O servidor em que a solução será implantada tem suporte a tais bibliotecas?
dentre outros.

Nesse post falarei de uma estratégia para essa atualização, porém, é importante ressaltar que isso não é a bala de prata para todos os projetos, e que sempre é bom acordar as decisões com o time, equipe de arquitetura e/ou liderança técnica responsável.

Utilizando um plugin

Um plugin bem interessante do Gradle é o Gradle Versions Plugin do Ben Manes. Sua aplicação é bem simples.

Utilizando o nosso projeto de referência, no nosso arquivo build.gradle na raiz do projeto podemos ver algo como o seguinte:

plugins {
    ...
    id "com.github.ben-manes.versions" version "$versionsVersion" apply false
    ...
}

...

subprojects {
    if (it.name != 'applications') {
        ...
        apply from: "$rootDir/plugins/docs.gradle"
        ...
    }
}

As configurações do arquivo plugins/docs.gradle serão melhor explicadas adiante.

Caso você esteja com dúvida sobre esses $ no código, dá uma olhada no post anterior em que falamos sobre Variáveis de projeto.

Essa primeira parte da configuração nos ajuda a buscar as atualizações de todas as nossas bibliotecas através da seguinte task do Gradle:

foo@bar:~$ ./gradlew dependencyUpdates

Executando a task vamos ter um resultado semelhante a:

./gradlew dependencyUpdates

------------------------------------------------------------
:applications:cadastro Project Dependency Updates (report to plain text file)
------------------------------------------------------------

The following dependencies are using the latest milestone version:
 - com.approvaltests:approvaltests:18.5.0
 - com.github.database-rider:rider-cdi:1.35.0
 - com.github.database-rider:rider-core:1.35.0
 - com.google.code.gson:gson:2.10
 - org.mapstruct:mapstruct:1.5.3.Final
 - org.mapstruct:mapstruct-processor:1.5.3.Final
 - stax:stax:1.2.0

The following dependencies have later milestone versions:
 - io.opentracing.contrib:opentracing-jdbc [0.2.4 -> 0.2.15]
     https://github.com/opentracing-contrib/java-jdbc
 - io.quarkus:io.quarkus.gradle.plugin [2.14.3.Final -> 3.0.0.Alpha2]
 - io.quarkus:quarkus-arc [2.14.3.Final -> 3.0.0.Alpha2]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-arc-deployment [2.14.3.Final -> 3.0.0.Alpha2]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-config-yaml [2.14.3.Final -> 3.0.0.Alpha2]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-config-yaml-deployment [2.14.3.Final -> 3.0.0.Alpha2]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-core-deployment [2.14.3.Final -> 3.0.0.Alpha2]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-flyway [2.14.3.Final -> 3.0.0.Alpha2]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-flyway-deployment [2.14.3.Final -> 3.0.0.Alpha2]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-hibernate-orm-panache [2.14.3.Final -> 3.0.0.Alpha2]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-hibernate-orm-panache-deployment [2.14.3.Final -> 3.0.0.Alpha2]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-hibernate-validator [2.14.3.Final -> 3.0.0.Alpha2]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-hibernate-validator-deployment [2.14.3.Final -> 3.0.0.Alpha2]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-jdbc-postgresql [2.14.3.Final -> 3.0.0.Alpha2]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-jdbc-postgresql-deployment [2.14.3.Final -> 3.0.0.Alpha2]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-junit5 [2.14.3.Final -> 3.0.0.Alpha2]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-resteasy-jsonb [2.14.3.Final -> 3.0.0.Alpha2]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-resteasy-jsonb-deployment [2.14.3.Final -> 3.0.0.Alpha2]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-smallrye-jwt [2.14.3.Final -> 3.0.0.Alpha2]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-smallrye-jwt-deployment [2.14.3.Final -> 3.0.0.Alpha2]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-smallrye-metrics [2.14.3.Final -> 3.0.0.Alpha2]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-smallrye-metrics-deployment [2.14.3.Final -> 3.0.0.Alpha2]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-smallrye-openapi [2.14.3.Final -> 3.0.0.Alpha2]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-smallrye-openapi-deployment [2.14.3.Final -> 3.0.0.Alpha2]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-smallrye-opentracing [2.14.3.Final -> 3.0.0.Alpha2]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-smallrye-opentracing-deployment [2.14.3.Final -> 3.0.0.Alpha2]
     https://github.com/quarkusio/quarkus
 - io.quarkus.platform:quarkus-bom [2.14.3.Final -> 3.0.0.Alpha2]
     https://github.com/quarkusio/quarkus-platform
 - io.rest-assured:rest-assured [4.5.1 -> 5.3.0]
     http://code.google.com/p/rest-assured
 - org.testcontainers:postgresql [1.17.5 -> 1.17.6]
     https://testcontainers.org

Gradle release-candidate updates:
 - Gradle: [7.6: UP-TO-DATE] 
------------------------------------------------------------

Nesse caso, removi os logs referentes aos demais subprojetos só para termos um resultado menor.

Podemos ver por exemplo que as seguintes dependências estão atualizadas no nosso projeto:

The following dependencies are using the latest milestone version:
  - com.approvaltests:approvaltests:18.5.0
  - com.github.database-rider:rider-cdi:1.35.0
  - com.github.database-rider:rider-core:1.35.0
  - com.google.code.gson:gson:2.10
  - org.mapstruct:mapstruct:1.5.3.Final
  - org.mapstruct:mapstruct-processor:1.5.3.Final
  - stax:stax:1.2.0

E que a dependência do opentracing-jdbc está desatualizada:

The following dependencies have later milestone versions:
  - io.opentracing.contrib:opentracing-jdbc [0.2.4 -> 0.2.15]

No entanto, temos um efeito colateral da forma como o plugin está funcionando. E isso pode ser visto em todas as dependências do Quarkus que estamos usando, a sugestão de atualização para versão 3.0.0.Alpha2:

  - io.quarkus:io.quarkus.gradle.plugin [2.14.3.Final -> 3.0.0.Alpha2]

Na maioria das vezes não queremos bibliotecas de Release, Alpha ou Beta no nosso projeto por não serem versões finais, e poderem conter alterações futuras. Para resolver esse problema, o próprio plugin nos oferece uma solução em suas configurações. No nosso caso, podemos encontrar elas em plugins/docs.gradle; eu havia comentado elas para evidenciar o problema anterior:

apply plugin: "com.github.ben-manes.versions"
...

dependencyUpdates {
    checkForGradleUpdate = true
    outputFormatter = "json"
    outputDir = "build/reports/docs/dependencyUpdates"
    reportfileName = "report"

    resolutionStrategy = {
        componentSelection { rules ->
            rules.all { ComponentSelection selection ->
                boolean rejected = ["alpha", "beta", "rc", "cr", "m"].any { qualifier ->
                    selection.candidate.version ==~ /(?i).*[.-]${qualifier}[.\d-]*/
                }
                if (rejected) {
                    selection.reject("Release candidate")
                }
            }
        }
    }
}

Executando novamente a task, nosso resultado para :applications:cadastro é o seguinte:

./gradlew dependencyUpdates

------------------------------------------------------------
:applications:cadastro Project Dependency Updates (report to plain text file)
------------------------------------------------------------

The following dependencies are using the latest milestone version:
 - com.approvaltests:approvaltests:18.5.0
 - com.github.database-rider:rider-cdi:1.35.0
 - com.github.database-rider:rider-core:1.35.0
 - com.google.code.gson:gson:2.10
 - io.quarkus.platform:quarkus-bom:2.14.3.Final
 - org.mapstruct:mapstruct:1.5.3.Final
 - org.mapstruct:mapstruct-processor:1.5.3.Final
 - stax:stax:1.2.0

The following dependencies have later milestone versions:
 - io.opentracing.contrib:opentracing-jdbc [0.2.4 -> 0.2.15]
     https://github.com/opentracing-contrib/java-jdbc
 - io.quarkus:io.quarkus.gradle.plugin [2.14.3.Final -> 2.15.0.Final]
 - io.quarkus:quarkus-arc [2.14.3.Final -> 2.15.0.Final]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-arc-deployment [2.14.3.Final -> 2.15.0.Final]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-config-yaml [2.14.3.Final -> 2.15.0.Final]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-config-yaml-deployment [2.14.3.Final -> 2.15.0.Final]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-core-deployment [2.14.3.Final -> 2.15.0.Final]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-flyway [2.14.3.Final -> 2.15.0.Final]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-flyway-deployment [2.14.3.Final -> 2.15.0.Final]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-hibernate-orm-panache [2.14.3.Final -> 2.15.0.Final]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-hibernate-orm-panache-deployment [2.14.3.Final -> 2.15.0.Final]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-hibernate-validator [2.14.3.Final -> 2.15.0.Final]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-hibernate-validator-deployment [2.14.3.Final -> 2.15.0.Final]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-jdbc-postgresql [2.14.3.Final -> 2.15.0.Final]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-jdbc-postgresql-deployment [2.14.3.Final -> 2.15.0.Final]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-junit5 [2.14.3.Final -> 2.15.0.Final]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-resteasy-jsonb [2.14.3.Final -> 2.15.0.Final]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-resteasy-jsonb-deployment [2.14.3.Final -> 2.15.0.Final]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-smallrye-jwt [2.14.3.Final -> 2.15.0.Final]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-smallrye-jwt-deployment [2.14.3.Final -> 2.15.0.Final]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-smallrye-metrics [2.14.3.Final -> 2.15.0.Final]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-smallrye-metrics-deployment [2.14.3.Final -> 2.15.0.Final]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-smallrye-openapi [2.14.3.Final -> 2.15.0.Final]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-smallrye-openapi-deployment [2.14.3.Final -> 2.15.0.Final]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-smallrye-opentracing [2.14.3.Final -> 2.15.0.Final]
     https://github.com/quarkusio/quarkus
 - io.quarkus:quarkus-smallrye-opentracing-deployment [2.14.3.Final -> 2.15.0.Final]
     https://github.com/quarkusio/quarkus
 - io.rest-assured:rest-assured [4.5.1 -> 5.3.0]
     http://code.google.com/p/rest-assured
 - org.testcontainers:postgresql [1.17.5 -> 1.17.6]
     https://testcontainers.org

Gradle release-candidate updates:
 - Gradle: [7.6: UP-TO-DATE]

------------------------------------------------------------

Problema de atualização de bibliotecas resolvido? É só ir no nosso gradle.properties e pronto.

Americas Got Talent What GIF by iOne Digital - Find & Share on GIPHY

Discover & share this Americas Got Talent What GIF by iOne Digital with everyone you know. GIPHY is how you search, share, discover, and create GIFs.

giphy.com

O que fizemos foi apenas uma forma de evidenciar quais as bibliotecas que estão desatualizadas.

Antes de mudar as versões de todas as que estão aparecendo como desatualizadas é importante validarmos se isso não impacta as outras bibliotecas do nosso projeto. Em muitos casos, uma biblioteca utiliza outras bibliotecas, o que chamamos de dependências transitivas. Com isso, para que uma biblioteca funcione corretamente é importante que suas dependências transitivas também estejam.

Pegue por exemplo a Spring Boot Starter Data JPA. Não vou me lembrar da versão exata, mas o Java teve uma grande mudança na versão 8, dentre elas, a adição de Optional.

Me lembro quando utilizei o plugin de versões para mudar a versão do Spring Boot em um outro projeto que eu estava trabalhando há alguns anos atrás, e de repente minhas classes de service começaram a dar problema. Ao investigar, percebi que a assinatura de alguns métodos mudaram, e ao invés de retornar uma entidade, estavam retornando Optional.

Nesse caso em específico, eu consegui mudar o meu código para que a atualização fizesse sentido, mas imagina se o problema fosse em uma classe de dependência transitiva que temos no projeto.

Como então resolver o problema de saber se a atualização de uma dependência impacta ou não outras dependências, e consequentemente o projeto? Podemos ir na tentativa e erro, subindo nossa aplicação e vendo se todos os fluxos dela continuam funcionando. Mas será que não tem uma forma melhor?

Continuous Integration

Em posts mais adiante falaremos sobre GitLab e pipelines. Quando falarmos sobre pipelines discorreremos sobre a importância do processo de automação dado o número de alterações de um projeto por várias pessoas.

Uma forma que poderíamos fazer seria então termos a nossa fase de testes executada em nossa pipeline sempre que um merge request for realizado, por exemplo.

Podemos agora fazer mudanças em versões de uma biblioteca e ver se nossos testes não quebram. Para essa abordagem é importante que confiemos nos nossos testes e na quantidade de camadas cobertas por eles.

Quando digo em confiar em nossos testes, me refiro aos seguintes testes que muitas vezes encontramos em nossos projetos:

import io.quarkus.test.junit.QuarkusTest;
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;

@QuarkusTest
public class Teste {

    private int adicao(int a, int b) {
        return a + b;
    }

    @Test
    void deveAdicionar() {
        Assertions.assertNotNull(adicao(1, 2));
    }
}

O teste com assertNotNull pode nos dar um falso positivo sobre o funcionamento do nosso método. Imagine por exemplo que um desenvolvedor subiu uma versão mudando o método para algo como:

private int adicao(int a, int b) {
    return a - b;
}

Nosso teste não iria quebrar! Bem importante usar testes com assertNotNull com parcimônia.

Esse foi apenas um exemplo de teste que poderia ser melhor testado, mas imagina se fizermos testes que não quebrem, porém, quando fizermos o deploy em produção aparecerem incompatibilidades.

Uma abordagem que podemos seguir para saber se temos bons testes foi escrita por @alexandreaquiles:

Testes de mutantes: quem vigia os vigilantes? | Alura

Quis custodiet ipsos custodes? - Decimus Junius Juvelanis A frase acima, do poeta romano Juvelanis, é geralmente traduzida como: "Quem vigia os vigilant

alura.com.br

Mas voltando à atualização das nossas bibliotecas, não seria maravilhoso se tivesse uma forma melhor do que nós mesmos abrirmos merges request para cada mudança?

Dependabot

O Dependabot é uma solução que funciona com Ruby, JavaScript, Python, PHP, Elixir, Elm, Go, Rust, Java e .NET.

E seu funcionamento se dá em uma constante validação de novas versões e abertura de merge requests para um repositório configurado. Não configurei nesse projeto, mas vocês podem ver a ideia dele nesse outro repositório que criei.

Com isso, é possível aprovar ou não os merge requests que o Dependabot fará para o nosso projeto.

Conclusão

A atualização de dependências de um projeto é um processo que poderá ser necessário em projetos, porém é importante avaliarmos os impactos das mesmas e consequências em outras bibliotecas do projeto.

Soluções como Gradle Versions Plugin ou Dependabot podem fazer parte do nosso processo para uma maior assertividade na alterações de tais versões, atrelados a processos como Continuous Integration.

Esse post faz parte de uma série sobre Cursos que formaram meu caráter: Desenvolvimento web com Quarkus.

A série completa é:

Talk is cheap show me the code
Utilizando Gradle ao invés de Maven
Plugins do Gradle: Gerenciador de versões de bibliotecas com Versions
Plugins do Gradle: Saudades do Maven, relatórios com Project-report
Plugins do Gradle: API First com o OpenAPI Generator
Plugins do Gradle: API First com o OpenAPI Generator para APIs reativas
Plugins do Gradle: Validação de vulnerabilidades de dependências com OWASP Dependency Check
Plugins do Gradle: Lint com Spotless [não publicado]
GitLab: Motivação para a escolha [não publicado]
GitLab: Considerações sobre o Prettier em pipelines [não publicado]
Gitmoji [não publicado]
SDK Man [não publicado]
Pré commit hook [não publicado]
application.yml: Utilizando YML em propriedades de aplicação [não publicado]
application.yml: Utilizando variáveis de ambiente [não publicado]
application.yml: Sobrescrevendo opções em teste [não publicado]
Mapstruct: Utilizando expressões para mapeamentos [não publicado]
Microprofile SecurityScheme: Sobrescrevendo tokenUrl [não publicado]
Prometheus: O problema simples que me custou algumas horas [não publicado]
quarkus-hibernate-reactive-panache: Utilizando as vantagens do Hibernate em projetos reativos [não publicado]
Testcontainers: Configuração para projetos reativos [não publicado]

Cursos que formaram meu caráter: Utilizando Gradle ao invés de Maven

Arthur Fonseca — Mon, 12 Dec 2022 20:01:24 +0000

"Pois as coisas que temos de aprender antes de podermos fazê-las, aprendemos fazendo-as." Aristóteles

Nesse segundo posts falaremos sobre o Gradle, uma ferramenta de automação que ajuda no gerenciamento de ciclo de vida de projetos. Vantagens, desvantagens e motivos que me fizeram mudar o projeto de Maven para Gradle.

Esse artigo faz parte de uma série, abaixo é possível encontrar a lista completa de artigos.

Estamos nos baseando no curso Desenvolvimento web com Quarkus do @viniciusfcf.

O repositório em que estamos nos baseando é:

udemy / Desenvolvimento Web com Quarkus / ifood · GitLab

GitLab.com

gitlab.com

Gradle 101 — History so far…

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.

Foi então que em 11 de Novembro de 2016, um commit simples foi um marco fundamental na minha carreira:

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

Naquela época eu trabalhava em um instituto de pesquisas, o IBTI, e @felipebelluco uma vez veio me perguntar se eu estava a fim de conhecer "umas coisas diferenciadas".

Ele trabalhava com Android, mas me falou que era possível utilizar Gradle em projetos de backend. Em um instituto de pesquisas o que você tem que fazer é experimentar coisas, e lá fui eu; algo semelhante ao que escrevi em um post sobre Paul Arden e experimentar coisas novas.

Parti da seguinte premissa: se isso vai "substituir" o Maven, precisa fazer o que ele faz; então, de posse de um projeto Maven criei um build.gradle e tentei a compilação do projeto até que ele funcionasse como funcionava o meu pom.xml.

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.

A timeline de ferramentas de gerenciamento de ciclo de vida de projetos no mundo Java foi mais do que uma troca entre Maven e Gradle, e pode ser detalhada como:

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

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.

Trainings | Gradle Enterprise

gradle.com

É muito fácil olhar para o Maven hoje e pensar que existem outras formas de fazer as coisas. Para o problema que tínhamos, o Maven era e continua sendo uma excelente solução.

E que problema era esse?

Como versionar dependências que usamos no projeto para não ficarmos com projetos grandes demais (imagina versionar os JARs de um projeto...)? 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. Com isso, aproveitamos da vantagem de padronização de estrutura proporcionada pelo nosso arquivo pom.xml

Para quem não sabe, aquelas primeiras linhas do pom.xml são muito importantes por definirem a estrutura do nosso arquivo.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
</project>

Já pensou em seguir o seguinte link https://maven.apache.org/xsd/maven-4.0.0.xsd do schemaLocation?

Stress I Need A Drink GIF - Find & Share on GIPHY

Discover & share this Stress GIF with everyone you know. GIPHY is how you search, share, discover, and create GIFs.

giphy.com

Nesse arquivo você consegue ver cada tag do pom.xml, bem como a quantidade mínima e máxima de repetições delas e que outras tags podem ser contidas dentro.

Nesse ponto, cheguei à conclusão que a discussão entre Maven e Gradle depende de uma série de fatores. 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 | Gradle vs Maven Comparison

High-level performance and feature comparison between Gradle and Maven

gradle.org

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

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.

E para quem acha que o Gradle 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.

Gradle ao invés de Maven, o que muda?

Wrapper

gradlew e gradlew.bat, esses são dois caras que muitas pessoas têm em seus projetos e não sabem para que servem. Para quem usa Maven temos o mvnw e o mvnw.cmd também.

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.

No arquivo build.gradle na raiz do projeto é possível encontrar o seguinte bloco de código:

wrapper {
    gradleVersion = "$gradleWrapperVersion"
}

$gradleWrapperVersion refere-se a uma variável do projeto escrita no arquivo gradle.properties, neste caso, a versão que estamos usando é a 7.6. Caso haja uma alteração de versão no Gradle é possível alterar a variável $gradleWrapperVersion e executar o seguinte comando:

foo@bar:~$ ./gradlew wrapper

Isso atualizará o gradle-wrapper.jar contido na pasta gradle/wrapper.

Variáveis de projeto

A utilização de variáveis de projeto vão estar presentes em todo o projeto, desde plugins:

plugins {
    id "com.diffplug.spotless" version "$spotlessVersion" apply false
    id "com.github.ben-manes.versions" version "$versionsVersion" apply false
    id "java"
    id "org.openapi.generator" version "$openApiGenVersion" apply false
    id "org.owasp.dependencycheck" version "$dependencyCheckVersion" apply false
}

Até dependências:

dependencies {
    implementation enforcedPlatform("${quarkusPlatformGroupId}:${quarkusPlatformArtifactId}:${quarkusPlatformVersion}")
    annotationProcessor "org.mapstruct:mapstruct-processor:$mapstructVersion"
    implementation libs.mapstruct
    implementation libs.quarkus
    testImplementation libs.test
}

Agrupando dependências

O Gradle possui um mecanismo bem interessante de reaproveitamento de código, como por baixo possuímos uma linguagem de programação, no nosso caso, usei o Groovy, mas já é possível usar o Kotlin (apesar de eu ainda não ter visto grande vantagem em mudar de Groovy para Kotlin, mas isso vai ser tema para outro post, quando eu experimentar substituir o Groovy por Kotlin em um novo projeto).

ext.libs = [
    quarkus  : [
        "io.quarkus:quarkus-arc",
        "io.quarkus:quarkus-config-yaml",
        "io.quarkus:quarkus-flyway",
        "io.quarkus:quarkus-jdbc-postgresql",
        "io.quarkus:quarkus-smallrye-openapi"
    ],
    mapstruct: [
        "org.mapstruct:mapstruct:$mapstructVersion"
    ],
    test     : [
       "com.approvaltests:approvaltests:$approvalTestsVersion",
        "com.google.code.gson:gson",
        "io.quarkus:quarkus-junit5",
        "io.rest-assured:rest-assured",
        "org.testcontainers:postgresql:$testcontainersVersion",
        "stax:stax:$staxVersion"
    ]
]

Desta forma é possível fazer o import de bibliotes da seguinte forma:

dependencies {
    ...
    implementation libs.mapstruct
    implementation libs.quarkus
    testImplementation libs.test
}

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-> implementation "org.jetbrains.kotlin:$a:$kotlinVersion"
    }
}

No exemplo acima estamos fazendo um forEach para cada artefato contido no Array kotlinArtifacts e utilizando o implementation com o mesmo groupId org.jetbrains.kotlin (vantagens de se utilizar uma linguagem de programação).

Nesse segundo exemplo é possível ver uma coisa bem interessante, a diferença entre aspas simples e aspas duplas para o Groovy. Resumindo, com aspas duplas é possível fazer interpolação de String, e com isso fazer a substituição da variável $kotlinVersion quando da implementation de um artefato. Teríamos algo como o seguinte ao final do nosso forEach:

implementation "org.jetbrains.kotlin:kotlin-allopen:1.3.31"
implementation "org.jetbrains.kotlin:kotlin-noarg:1.3.31"
implementation "org.jetbrains.kotlin:kotlin-gradle-plugin:1.3.31"

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.

subprojects {
    if (it.name != 'applications') {
        apply plugin: "java"
        apply from: "$rootDir/plugins/java.gradle"
        apply from: "$rootDir/plugins/docs.gradle"
        apply from: "$rootDir/plugins/lint.gradle"
        apply from: "$rootDir/plugins/mapstruct.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 Java, documentação de projeto, Lint, MapStruct e segurança. Em postagens futuras falaremos sobre cada um deles.

O build.gradle fica muito mais limpo.

Multi project Gradle

Como no Maven, é possível trabalhar com multi-projetos no Gradle. Particularmente nesse ponto acho o Maven um pouco melhor, bem como na parte de definição de Parent-Project.

O grande pulo do gato para o Gradle vai estar no arquivo settings.gradle.

rootProject.name = "ifood"

include "applications:cadastro"
include "applications:marketplace"
include "applications:pedido"

Preferi agrupar todos os projetos dentro de uma pasta chamada applications. Como utilizo outras pastas para configurações (configs) e plugins, achei melhor agrupar uma pasta com os códigos em Java.

Essa configuração já é o suficiente para termos os subprojetos vinculados.

subprojects

Com o Gradle é possível definir de uma forma global configurações que serão utilizadas para todo o projeto e/ou para os subprojetos.

subprojects {
    if (it.name != 'applications') {
        apply plugin: "java"
        apply from: "$rootDir/plugins/java.gradle"
        apply from: "$rootDir/plugins/docs.gradle"
        apply from: "$rootDir/plugins/lint.gradle"
        apply from: "$rootDir/plugins/mapstruct.gradle"
        apply from: "$rootDir/plugins/security.gradle"

        repositories {
            mavenCentral()
            mavenLocal()
        }

        dependencies {
            implementation enforcedPlatform("${quarkusPlatformGroupId}:${quarkusPlatformArtifactId}:${quarkusPlatformVersion}")
            annotationProcessor "org.mapstruct:mapstruct-processor:$mapstructVersion"
            implementation libs.mapstruct
            implementation libs.quarkus
            testImplementation libs.test
        }

        test {
            useJUnitPlatform()
            maxParallelForks = 2
            testLogging {
                displayGranularity = 2
                events("FAILED", "SKIPPED")
            }
            systemProperty "java.util.logging.manager", "org.jboss.logmanager.LogManager"
        }
    }
}

E caso precisemos de configurações específicas em um subprojeto é possível utilizar a seguinte estratégia contida em applications/cadastro/build.gradle

plugins {
    id "io.quarkus"
}

group "com.gitlab.arthurfnsc.ifood"
version "1.0.0-SNAPSHOT"

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

dependencies {
    implementation "io.opentracing.contrib:opentracing-jdbc"
    implementation "io.quarkus:quarkus-hibernate-orm-panache"
    implementation "io.quarkus:quarkus-hibernate-validator"
    implementation "io.quarkus:quarkus-resteasy-jsonb"
    implementation "io.quarkus:quarkus-smallrye-jwt"
    implementation "io.quarkus:quarkus-smallrye-metrics"
    implementation "io.quarkus:quarkus-smallrye-opentracing"
    testImplementation "com.github.database-rider:rider-cdi:$dbRiderVersion"
    testImplementation "com.github.database-rider:rider-core:$dbRiderVersion"
}

Nesse caso, além das dependências definidas no bloco subprojects adicionamos dependências e um plugin específico.

Conclusão

A utilização de Gradle foi uma escolha minha e em nada impacta no curso criado pelo @viniciusfcf.

Apesar de uma série de vantagens propostas, sempre é importante analisar o contexto do projeto a ser desenvolvido, bem como a expertise da equipe para a definição de uma ou outra opção.

Esse post faz parte de uma série sobre Cursos que formaram meu caráter: Desenvolvimento web com Quarkus.

A série completa é:

Talk is cheap show me the code
Utilizando Gradle ao invés de Maven
Plugins do Gradle: Gerenciador de versões de bibliotecas com Versions
Plugins do Gradle: Saudades do Maven, relatórios com Project-report
Plugins do Gradle: API First com o OpenAPI Generator
Plugins do Gradle: API First com o OpenAPI Generator para APIs reativas
Plugins do Gradle: Validação de vulnerabilidades de dependências com OWASP Dependency Check
Plugins do Gradle: Lint com Spotless [não publicado]
GitLab: Motivação para a escolha [não publicado]
GitLab: Considerações sobre o Prettier em pipelines [não publicado]
Gitmoji [não publicado]
SDK Man [não publicado]
Pré commit hook [não publicado]
application.yml: Utilizando YML em propriedades de aplicação [não publicado]
application.yml: Utilizando variáveis de ambiente [não publicado]
application.yml: Sobrescrevendo opções em teste [não publicado]
Mapstruct: Utilizando expressões para mapeamentos [não publicado]
Microprofile SecurityScheme: Sobrescrevendo tokenUrl [não publicado]
Prometheus: O problema simples que me custou algumas horas [não publicado]
quarkus-hibernate-reactive-panache: Utilizando as vantagens do Hibernate em projetos reativos [não publicado]
Testcontainers: Configuração para projetos reativos [não publicado]

Cursos que formaram meu caráter: Desenvolvimento web com Quarkus - Talk is cheap show me the code

Arthur Fonseca — Mon, 12 Dec 2022 06:20:41 +0000

O preguiçoso muito quer e nada alcança. [Provérbios 13:4a]

Preciso confessar um problema que tenho: Acumulação de coisas digitais!

O advento da era em que estamos nos proporcionou uma série de benefícios, como a disponibilidade de informações e conteúdos a "um clique de distância".

A Udemy, por exemplo, é uma plataforma de ensino que permite o aprendizado de diversas ferramentas, frameworks, metodologias, dentre outras coisas. O que percebi dos meus estudos com ela, no entanto, é que eu não terminei 10% dos cursos que tenho. Muitas das vezes acabava com preguiça de finalizar um curso dado a máxima do término de projetos:

Visando melhorar esses números, resolvi realizar os cursos e escrever insights dos mesmos, exercitando hard skills, bem como a escrita em português, inglês e espanhol.

O curso que resolvi começar foi o curso Desenvolvimento web com Quarkus do Vínicius Ferraz Campos Florentino.

O código do curso do Vinícius se encontra no seu GitHub.

viniciusfcf / udemy-quarkus

Código apresentado no curso de desenvolvimento completo com Quarkus no Udemy

Curso disponível na Udemy

Código criado no curso de desenvolvimento Web com Quarkus no Udemy

Clique aqui e acesse o curso

View on GitHub

O código que irei apresentar se encontra no meu GitLab. Em um dos tópicos adiante explicarei a motivação da escolha do GitLab para versionamento de código.

udemy / Desenvolvimento Web com Quarkus / ifood · GitLab

GitLab.com

gitlab.com

Motivação

Meu objetivo ao realizar o curso foi aplicar algumas alterações em sua estrutura e arquitetura, visando consolidar outros conhecimentos e técnicas que utilizo em projetos com Java e Kotlin na ília Digital.

Importante ressaltar que o que escreverei aqui não substitui o curso do Vinícius, nem tão pouco que o código apresentado no curso não alcançou seu objetivo de ensinar os alunos.

Vários pontos referentes ao Quarkus são detalhados no curso do Vinícius, e não será foco desses artigos a explicação deles, como por exemplo: Flyway, Grafana, Keycloak, dentre outros.

Algumas das alterações, por exemplo, foram de evolução de versão de bibliotecas já que a última atualização do curso se deu em Outubro de 2020. Outras foram apenas escolhas arquiteturais minhas, como o conceito de API First com OpenAPI Generator e a utilização de Gradle ao invés de Maven que em nada desmerecem a solução utilizada pelo Vinícius. Para cada uma dessas escolhas mostrarei as vantagens e desvantagens.

Sendo assim, recomendo a todos a realização do curso caso queiram uma visão sobre o Quarkus, bem como seguirem o canal do YouTube do Vinícius para mais novidades sobre o framework. Um dos últimos vídeos dele sobre Apache Camel está na minha lista de vídeos para ver.

Isso me lembrou um post do Mário Rezende no Linkedin, e para variar que também tenho três cursos da Udemy de Camel que ainda não fiz ahahahahahahahahahahahah.

Mario Rezende on LinkedIn: #apachecamel #java | 16 comments

🐪 #ApacheCamel é o caviar da Dev #JAVA ☕ "Nunca vi, nem comi, só ouço falar" 😁 Mas sério... é uma peça de Software incrível 🏆 | 16 comments on LinkedIn

linkedin.com

Ainda estou terminando o curso do Vinícius, mas já posso adiantar alguns tópicos que irei abordar. Sendo assim, te aguardo nos próximos posts.

Esse post faz parte de uma série sobre Cursos que formaram meu caráter: Desenvolvimento web com Quarkus.

A série completa é:

Talk is cheap show me the code
Utilizando Gradle ao invés de Maven
Plugins do Gradle: Gerenciador de versões de bibliotecas com Versions
Plugins do Gradle: Saudades do Maven, relatórios com Project-report
Plugins do Gradle: API First com o OpenAPI Generator
Plugins do Gradle: API First com o OpenAPI Generator para APIs reativas
Plugins do Gradle: Validação de vulnerabilidades de dependências com OWASP Dependency Check
Plugins do Gradle: Lint com Spotless [não publicado]
GitLab: Motivação para a escolha [não publicado]
GitLab: Considerações sobre o Prettier em pipelines [não publicado]
Gitmoji [não publicado]
SDK Man [não publicado]
Pré commit hook [não publicado]
application.yml: Utilizando YML em propriedades de aplicação [não publicado]
application.yml: Utilizando variáveis de ambiente [não publicado]
application.yml: Sobrescrevendo opções em teste [não publicado]
Mapstruct: Utilizando expressões para mapeamentos [não publicado]
Microprofile SecurityScheme: Sobrescrevendo tokenUrl [não publicado]
Prometheus: O problema simples que me custou algumas horas [não publicado]
quarkus-hibernate-reactive-panache: Utilizando as vantagens do Hibernate em projetos reativos [não publicado]
Testcontainers: Configuração para projetos reativos [não publicado]

SDKMan, adding unlisted versions

Arthur Fonseca — Wed, 20 Oct 2021 00:56:30 +0000

SDKMan is a fantastic tool, I believe no one has doubts! Since I installed it, my concerns with Gradle, Java, Kotlin versions, among other SDKs ended... As a JVM developer, just not needing to adjust the infamous JAVA_HOME, M2_HOME and others, have already turned my days into happier days.

Something, however, gave me a certain headache that I would like to share with you:

I recently started implementing a project with Java 12. At first, I thought, just install this version with SDKMan, however, I was mistaken... the version didn't appear on any of the vendors when I ran sdk list java.

I still don't understand the reason for this gap, but I started to think about alternatives... I could install the version 16 and make use of the Java retrocompatibility, however, this started to look as a work around.

I even thought about installing the pre-SDKMan, however, I was wondering how the Java version management at two distinct points on my operating system, in addition to possible changes to my POM to avoid compilation version errors. After some research I found post on StackOverflow, a solution that I thought was more elegant.:

It seems that downloading the missing version, then unpacking to: ~/.sdkman/candidates/java/ then renaming the extracted directory solves the problem.

With that, I continued using only 1 manager of Java in my operational system, taking advantage of the facilities of SDKMan! SDKMan is life!!!

SDKMan, adicionando versões não listadas

Arthur Fonseca — Sun, 17 Oct 2021 01:41:14 +0000

Que o SDKMan é uma ferramenta fantástica creio que ninguém tem dúvidas. Desde que instalei ele minhas preocupações com versões do Gradle, Java, Kotlin, dentre outras SDKs terminaram... Como desenvolvedor JVM só de não precisar ajustar os famigerados JAVA_HOME, M2_HOME e outros, já transformaram meus dias em dias mais felizes.

Algo, no entanto, me deu uma certa dor de cabeça que gostaria de compartilhar com vocês:

Recentemente comecei a implementar um projeto com Java 12. De início, pensei, basta instalar essa versão com o SDKMan, porém, eu estava enganado... a versão não aparecia em nenhum dos vendors quando eu executava sdk list java.

Ainda não entendi o porquê dessa lacuna, mas comecei a pensar em alternativas... eu poderia instalar a versão 16 e me fazer valer da retrocompatibilidade do Java, porém, isso começou a parecer uma belíssima de uma gambiarra.

Até pensei em instalar da maneira pré-SDKMan, porém, estava me perguntando como seria a gerência da versão do Java em dois pontos distintos no meu sistema operacional, além de possíveis alterações em meu POM para evitar erros de versão de compilação. Foi então que um post no StackOverflow trouxe uma solução que julguei mais elegante:

It seems that downloading the missing version, then unpacking to: ~/.sdkman/candidates/java/ then renaming the extracted directory solves the problem.

Com isso, continuei utilizando apenas 1 gerenciador de versões do Java, aproveitando as facilidades do SDKMan! SDKMan é vida!!!

Conhecimentos inesperados de um Tech Leader | Pesadelo na Cozinha: Introdução

Arthur Fonseca — Mon, 26 Apr 2021 16:06:40 +0000

Introdução

Recentemente em minhas buscas por programações para entretenimento me deparei com o programa Pesadelo na Cozinha apresentado por Erick Jacquin. Os episódios que usaremos no decorrer dos posts estão disponíveis no canal deles no YouTube.

Basicamente o programa nos mostra Jacquin interagindo com vários restaurantes e mostrando pontos de desorganização e desperdícios.

O foco da série que vou escrever não vai girar em torno da veracidade de tudo, porque eu às vezes fico com pé atrás em programas que as pessoas sabem estar sendo gravadas e agem de determinada maneira ¯|(ツ)/¯. Então, sim, tenho minhas dúvidas sobre a espontaneidade dos participantes, inclusive do Jacquin, mas isso não será problema para as análises que vamos fazer aqui.

Afinal, o que isso tem a ver com Tech Leader?

Uma das coisas que tento fazer é não desassociar meu “eu-profissional” do meu “eu-pessoal”. Quando vejo filmes, séries, leio livros, ouço músicas geralmente tento fazer paralelos dessas coisas com a minha vida de modo geral. Isso pode ser visto em alguns posts que escrevi como:

Não seja esse tipo de desenvolvedor: post inspirado no excelente mangá Terraformars e no seu paralelo com o mundo do desenvolvimento. Wolf Redfield é um desenvolvedor de software no mangá e essa parte da história mostra algo que muitos desenvolvedores passam diariamente, e algo, que como mostrado, tem um efeito devastador: necessidade de entregas cada vez mais rápidas e entregas cada vez maiores.
Departamento de Polícia da Física e Testes de software: post inspirado na HQ DPF onde as constantes físicas já não são mais constantes, e um paralelo como às vezes nossos “testes unitários” parecem testar coisas que “não confiamos”, como adicionar elemento a uma lista e testar em seguida que a lista não está vazia ¯|(ツ)/¯ ou testar se o save e findById do Spring Data… salvam… e… recuperam por id (para quem não trabalha com Spring, esses métodos já são dados pela interface que implementamos… testar o default nesse caso seria testar o framework, como se o próprio projeto spring-data não o fizesse). O objetivo do post é discutir o que são regras que são constantes e o que são regras passíveis de testar, um teste em que criamos um objeto com new e em seguida fazemos uma asserção para validar se ele não é nulo só quer dizer que não confiamos nas regras constantes da nossa linguagem.
Review O Ponto da Virada - Malcolm Gladwell: post em que faço um paralelo com um artigo chamado Test Infected de Kent Beck e Erich Gamma.
Série de livros de Paul Arden: nesses posts escrevo sobre 2 livros de Paul Arden e questões como feedback, discordância de pontos de vista, DevOps, até sobre como apliquei ArchUnit em um projeto o.O…

Realmente é bem interessante ler sobre o que você escreveu há um tempo…

Com o Pesadelo na Cozinha não foi diferente, ao acompanhar os episódios foi possível enxergar uma certa padronização de ações que davam para serem isoladas no “modus operandi” do programa:

Teste de resiliência/ exploratório individual, quando Jacquin pede vários pratos de uma vez só, validando a atenção no processamento das informações e em como tarefas “simultâneas” são executadas.
Teste de resiliência múltiplo, quando o restaurante é submetido a um pico de requisições em um dia cheio.
Validação de sobreposição de funções ou ausência de funções no time. Definição de Chefes.
Anti-Pattern “Ah, eu sempre digo isso mas ninguém me escuta”.
Anti-Pattern “Ah, só somos assim porque não temos x”.
Execução de um novo prato ensinado.
Falha e sucesso na execução de um novo prato ensinado.
Adesão de maquinário e novos pratos.
Falha e sucesso mesmo com novo maquinário e novos pratos ensinado.

Cada um desses pontos pode ser analisado sob uma ótica de liderança, falarei sobre a liderança técnica, mas poderia ser outra ou outra analogia.

Por exemplo, quando vejo pessoas que dizem que “só” não evoluíram por falta da ferramenta x, y ou z tem um ponto que geralmente esquecemos, que mesmo se tivéssemos a melhor ferramenta e melhores definições, ainda sim, precisamos estar prontos para executar isso. Isso fica bem evidente quando a equipe recebe todo um novo maquinário e isso não resolve os problemas deles, porque a questão não é a ferramenta pela ferramenta apenas, mas como extrair o melhor dela com nossas habilidades.

Outro exemplo é o anseio de pessoas em serem Chefes sem terem passado por desafios que as direciona a tal, algo semelhante ao que vemos de pessoas que estão no começo de suas carreiras e já querem ser sênior com pouco tempo, sem perceberem os desafios e exigências dessas funções.

Enfim… começarei a escrever cada um desses pontos em artigos separados, só ainda não fechei o número de posts, mas ao menos cada ponto mencionado acima dá um…

E você? Consegue enxergar mais alguma analogia? Se sim, me fala… Também irei escrever em outros idiomas como inglês e espanhol para treinar um pouco, sendo assim, qualquer sugestão de melhoria é bem-vinda. Uso muito o Grammarly e o Language Tool para isso, um mais focado em inglês e outro com suporte a mais idiomas.

Original post published at https://medium.com on April 25th, 2021.

Corda Blockchain | Desafio R3 — Pensamentos sobre minha metodologia de aprender algo novo (Parte 2: Sobre Documentação)

Arthur Fonseca — Thu, 17 Sep 2020 00:46:25 +0000

“Tem horas em que entender errado é pior do que não entender” Thiago Grulha

Nesse terceiro posts sobre Corda Blockchain falaremos sobre o documentação e README, uma etapa geralmente negligenciada por nós desenvolvedores.

Para que documentar algo que eu já sei?

Sempre que falo sobre documentação de um conhecimento me lembro do seguinte post que escrevi uma vez em que menciono uma história que o já famoso Felipe Belluco uma vez me disse:

Acho interessante que sempre que aprendermos um comando ou algo novo a gente crie uma documentação bem simples.

Isso me trouxe à mente um problema que eu já havia passado com um Gradle há um tempo atrás.

Como todo “bom programador”, criei um projeto para testar umas coisas, porém esqueci de versionar…

Dias depois, passei pelo mesmo problema que tinha resolvido nesse projeto, fui procurar para ver a solução, e tinha deletado o projeto…

Projeto Konami Code

Acho que todo mundo que já trabalhou com desenvolvimento já se deparou uma vez na vida com a situação de interagir com algo que não se faz a ideia de como simular o ambiente localmente ou como testar uma mudança antes de mandar quilo para produção.

Em um dos clientes que trabalhei, uma frase ficou bem marcada em minha mente:

“Você sabe como é, aqui na empresa temos vários projetos, mas cada um tem sua ‘manha’ para executar. Ai ficamos perdendo tempo tentando nos lembrar como fazer isso funcionar projeto a projeto”

Chamo esses projetos de Projetos Konami Code, precisamos de todo uma abstração, sorte, e execuções dos mais diversos comandos para fazer a solução “subir”.

O time cresceu, problema à vista

Outra problemática dessa abordagem é o crescimento do time… Não vamos conseguir passar tão simples os Konami Codes de todos os projetos que ele vai trabalhar, e ai, a gente vira a “própria documentação do código”:

“Como subo o projeto no IntelliJ? Como baixo essa dependência X que não encontro no Maven Repository? Meu projeto não compila, o que eu faço?”

Dentre outras perguntas…

A resposta para esses e outros problemas está na documentação do seu projeto.

Mas documentar o que? Tudo?

Na AIS Digital trabalhamos com ferramentas para documentação de projeto, porém, é bem interessante saber separar o que deveria ser documentado na página do projeto como um todo, e o que deveria ser documentado em cada repositório.

Aqui não vou trazer nenhuma receita de bolo, o ponto que eu sempre sigo é: documentar o máximo que você achar que é necessário, seja na página do projeto, seja no repositório.

Por exemplo: Um repositório que peguei na AIS Digital tinha documentado que para usar o container de um banco em específico era necessário aceitar os termos do mesmo, para podermos baixar a imagem; em outro documentei que em uma abordagem com API First era comum que após a geração de classes o projeto continuasse a apresentar erros porque a IDE ainda não tinha realizado a indexação das novas classes geradas, sendo necessário um refresh para isso.

O ponto aqui é: documente o máximo que tu acha que pode te ajudar a outra pessoa não precisar te mandar email, ligar, mandar Slack para saber como interagir com o projeto!

No caso de projetos no Github, geralmente tento documentar o máximo de coisas, pois não vou ter ferramentas como Confluence, Sharepoint e outras para essa documentação.

Vamos então falar sobre a documentação do nosso repositório no Github.

Conheça os recursos de Markdown de sua solução de versionamento

Diana Regina em um post descreveu com maestria alguns pontos que podem nos ajudar a melhorar a documentação de nosso repositório.

Filipe Dias, uma vez me mostrou esse repositório também, que pode nos ajudar a escrever Awesome READMEs.

Um ponto que os dois tem em comum é chamar a atenção para o suporte a Markdowns da solução de versionamento que se deseja usar…

Por exemplo, no caso do nosso projeto, vocês podem ver que a parte de Instruções nos itens Java 8 e Gradle (Opcional) são itens clicáveis que expandem.

Isso é possível graças a uma tag HTML dentro do README.md


<details><summary><b>Instruções</b></summary>

[Dados a serem ocultados]

</details>

E para os mais críticos que acreditam que Markdown não deve se misturar com HTML, no post Corda Blockchain | Desafio R3 — Pensamentos sobre minha metodologia de aprender algo novo (Parte 3: Sobre Lint) além de falarmos sobre Lint para Kotlin, falaremos sobre um Lint para Markdown.

Voltando a falar sobre tags HTML em Markdown, adivinhem então o que aconteceu quando tentei colocar essas mesmas tags em um projeto que eu estava participando que não estava no GitHub (não me lembro agora se foi no Bitbucket ou GitLab)?

Descobri que existia diferença entre interpretadores de Markdown de acordo com a solução de versionamento:

Em alguns deles você possui, inclusive, tags especiais, como [TOC] (Table of Contents). Essa tag cria um índice do seu projeto, e para tanto, cada cabeçalho irá se tornar um item com uma âncora de acesso “linkada”.

Sendo assim, uma dica é conheça o que você tem em mãos para facilitar sua documentação.

Executando o projeto

Quando pensei em documentar o nosso projeto, pensei em algumas informações e comandos como:

Obrigatoriedade do Java 8, incluindo um ponto importante para testes (que ainda não fiz o merge por conta da competição que estou participando, e por esse commit ter acontecido depois da data de entrega; esse merge pode ter sido realizado dependendo de quando você esteja vendo esse artigo, procure pela seção Erros ao rodar os testes);
Não obrigatoriedade de Gradle instalado na máquina para execução do projeto;
Como clonar o projeto;
Como gerar os nodes;
Como rodar os nodes;
Como executar a “aplicação do banco” e a “aplicação da corretora”
Dentre outras tasks importantes

Uma vez que o projeto é público, a ideia é tornar mais simples para outras pessoas interagirem com ele e poderem dar feedbacks de melhorias.

Plugins Gradle de documentação

Sobre a parte de documentação, também podemos usar plugins do Gradle. No nosso projeto, os utilizados para documentar estão descritos no arquivo plugins/docs.gradle. Mais sobre como utilizar plugins você pode ver em: Corda Blockchain | Desafio R3 — Pensamentos sobre minha metodologia de aprender algo novo (Parte 1: Sobre Gradle).

O Dokka gera a documentação de cada projeto contido no nosso repositório. Nesse caso, dentro do build de application/cordapp-contracts-states, application/cordapp-flows e application/rest-api é possível ver uma pasta dokka com um HTML de nossas classes. Ainda preciso configuração a agregação de todos os relatórios para o build da raiz.

O Project-Report está mais focado em relatórios de dependências de projeto e tasks de projeto.

O Gradle-Versions é um cara tão fera que resolvi dar para ele um post exclusivo, falaremos sobre ele em Corda Blockchain | Desafio R3 — Pensamentos sobre minha metodologia de aprender algo novo (Parte 4: Sobre Versões Desatualizadas de dependências).

Gitm😜ji e Gitm😜ji-Changelog

Utilizei Gitm😜ji para meus commits serem mais assertivos. A ideia é que uma pessoa pelo emoji tenha ideia do que o commit se propõe a fazer, para não precisar clicar em commit por commit para analisar.

A proposta é ter um commit por ação, para não ficar naqueles commits que alteram tudo no projeto e tu já nem controla mais isso depois. O uso de squash e rebase funcionam de forma linda com esse cara!

Um outro cara bem fera que pretendo usar é Gitm😜ji-Changelog, ele agrega seus commits por tags e facilita a geração de changelog.

No demais é isso… nos encontraremos no próximo post em que falarei sobre como iniciei minha jornada com Kotlin e como um bom Lint é (quase) tudo o que precisamos para aprender uma linguagem nova.

E você tem alguma consideração sobre README ou documentação de repositórios, 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 Afterimage | Unveil the Unseen

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

Corda Blockchain | Desafio R3 — Pensamentos sobre minha metodologia de aprender algo novo (Parte 1: Sobre Gradle)

Arthur Fonseca — Tue, 15 Sep 2020 21:28:37 +0000

“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.

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


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.

DEV Community: Arthur Fonseca

Cursos que formaram meu caráter: Desenvolvimento web com Quarkus - Validação de vulnerabilidades com OWASP Dependency Check

Vulnerabilidades

OWASP e CVE

Estou vulnerável, e agora?

Automatizando a descoberta de possíveis vulnerabilidades

Integração com SonarQube

dependency-check / dependency-check-sonar-plugin

Integrates Dependency-Check reports into SonarQube

Dependency-Check Plugin for SonarQube 8.x and 9.x

About Dependency-Check

Note

Ignorando falsos positivos

Conclusão

Cursos que formaram meu caráter: Desenvolvimento web com Quarkus - API First com o OpenAPI Generator para APIs reativas

OpenAPI Generator e APIs reativas

Motivation

Code changes

Tests

PR checklist

Considerações finais

Sobre a utilização de OpenAPI Gen para APIs reativas

Cursos que formaram meu caráter: Desenvolvimento web com Quarkus - API First com o OpenAPI Generator

SOA so far

OpenAPI abordagens

Escrita de contrato e implementação em uma linguagem de programação

Geração de contrato a partir de código

Geração de código a partir de contrato

Prós e contra de cada abordagem

Principais configuração em nosso projeto

Os primeiros "problemas" com OpenAPI e JAX-RS

Mais "problemas" com OpenAPI e JAX-RS

Describe the bug

Expected behavior

Actual behavior

How to Reproduce?

Output of uname -a or ver

Output of java -version

GraalVM version (if different from Java)

Quarkus version or git rev

Build tool (ie. output of mvnw --version or gradlew --version)

Additional information

Demais configurações

Conclusão e observações da decisão arquitetural

OpenAPI Generator sempre vai estar defasado com relação à especificação

OpenAPI Generator definitivamente não combina com Serverless

Cursos que formaram meu caráter: Desenvolvimento web com Quarkus - Saudades do Maven, relatórios com Project-report

Tradeoffs

Mas o que afinal de contas o Maven Site faz?

Mas e com o Gradle?

Conclusão

Cursos que formaram meu caráter: Desenvolvimento web com Quarkus - Gerenciador de versões de bibliotecas com Versions

O tempo passa, o tempo voa

Utilizando um plugin

Continuous Integration

Dependabot

Conclusão

Cursos que formaram meu caráter: Utilizando Gradle ao invés de Maven

Gradle 101 — History so far…

Gradle ao invés de Maven, o que muda?

Wrapper

Variáveis de projeto

Agrupando dependências

Definições externas

Multi project Gradle

subprojects

Conclusão

Cursos que formaram meu caráter: Desenvolvimento web com Quarkus - Talk is cheap show me the code

viniciusfcf / udemy-quarkus

Código apresentado no curso de desenvolvimento completo com Quarkus no Udemy

Curso disponível na Udemy

Motivação

SDKMan, adding unlisted versions

SDKMan, adicionando versões não listadas

Conhecimentos inesperados de um Tech Leader | Pesadelo na Cozinha: Introdução

Introdução

Afinal, o que isso tem a ver com Tech Leader?

Corda Blockchain | Desafio R3 — Pensamentos sobre minha metodologia de aprender algo novo (Parte 2: Sobre Documentação)

Para que documentar algo que eu já sei?

Projeto Konami Code

Output of `uname -a` or `ver`

Output of `java -version`

Build tool (ie. output of `mvnw --version` or `gradlew --version`)