Build

Quando usar: a cada mudança. O build do serviço é um Maven Wrapper dentro do módulo: não há instalação global, não há plugin mágico e não há passo que só existe no CI.

# o único pré-requisito é o JDK 26 no PATH — o Maven vem do ./mvnw do módulo
./mvnw -q verify        # o gate local: compila, roda os testes, confere
./mvnw -q package       # o JAR executável em target/

Os comandos rodam na raiz do módulo. O pom.xml gerado já declara o repositório Maven da empresa (nnumbers-public, o grupo do Nexus que também espelha o Maven Central): com um repositório local vazio e sem settings.xml, o ./mvnw resolve o console-service-parent, o SDK e os plugins de lá.

O que cada comando faz

Comando	O que roda
./mvnw -q compile	Só a compilação.
./mvnw -q test	Compila e roda os testes de unidade e de integração em JVM (surefire).
./mvnw -q verify	O gate: test + as sondas de processo (failsafe) + o que o pom.xml amarrar.
./mvnw -q package	O JAR executável (target/nns-<id>-<versão>.jar) — o mesmo que vai para a imagem.
./mvnw -q -DskipTests package	Só empacotar. Use quando já rodou o verify.

O wrapper (./mvnw, .mvn/wrapper/) está commitado: a versão do Maven não depende da máquina de quem roda. O POM do serviço herda de console-service-parent, que fixa as versões provadas (Spring Boot, driver do MySQL, Jackson) e traz o enforcer.

O POM do serviço

pom.xml (na raiz do módulo):

<parent>
  <groupId>br.com.nnumbers.console</groupId>
  <artifactId>console-service-parent</artifactId>
  <version>0.8.0-SNAPSHOT</version>
  <relativePath/>
</parent>

<groupId>br.com.nnumbers.console.sample</groupId>
<artifactId>nns-sample</artifactId>
<version>0.1.0</version>

<dependencies>
  <dependency>
    <groupId>br.com.nnumbers.console</groupId>
    <artifactId>console-sdk-spring-boot-starter</artifactId>
  </dependency>
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-test</artifactId>
    <scope>test</scope>
  </dependency>
</dependencies>

Duas coisas que surpreendem quem vem de um projeto Spring comum:

• A versão do serviço é a versão do módulo (0.1.0, a mesma do nnp/release.yaml). Ela entra no release_id e no marcador: mudar uma sem a outra é defeito de build.
• Os descritores não são copiados. O pom.xml lê nnp/*.yaml, nns/service.yaml e as migrations do lugar, na raiz do módulo, e as embute no classpath nos caminhos que o SDK conhece:

<resources>
  <resource>
    <directory>${nn.sample.root}</directory>
    <filtering>false</filtering>
    <includes>
      <include>nnp/release.yaml</include>
      <include>nnp/api.yaml</include>
      <include>nnp/iam.yaml</include>
      <include>nnp/placement.yaml</include>
      <include>nnp/audit.yaml</include>
      <include>nns/service.yaml</include>
    </includes>
  </resource>
  <resource>
    <directory>${nn.sample.root}/nns/internal/store/migrations</directory>
    <targetPath>br/com/nnumbers/console/sample/store/migrations</targetPath>
    <filtering>false</filtering>
    <includes><include>*.sql</include></includes>
  </resource>
  <resource>
    <directory>src/main/resources</directory>
  </resource>
</resources>

É por isso que o serviço lê os descritores reais na partida, sem depender de cópia sincronizada.

O que o enforcer recusa

O pai falha o build quando o módulo tenta sair do contrato: outro Java que não o 26, builder ou run image por tag em vez de digest, os perfis native/nativeTest, native-maven-plugin, Quarkus, AOT, JPA/Hibernate, Flyway e Liquibase no classpath.

O gate local, na prática

export NNC_TEST_MYSQL_DSN='usuário:senha@tcp(127.0.0.1:3306)/'   # a conta precisa de CREATE USER e de ALL … WITH GRANT OPTION sobre `nnt\_%`
./mvnw -q verify

No módulo de exemplo isso roda 41 testes: 12 de unidade e descritor, 7 de HTTP com autorização, 15 em MySQL real, 4 de migration e 3 do cliente de outro serviço. Sem a DSN, os de banco são pulados — e o resumo diz quantos foram.

Se você tem um repositório Maven local já populado e quer rodar sem rede:

./mvnw -q -o verify

Erros comuns

• Usar mvn do sistema em vez de ./mvnw — outra versão do Maven, outro resultado.
• Compilar com outro JDK — o enforcer recusa, e é bom que recuse: o alvo é Java 26.
• Mudar a versão do serviço sem mudar o nnp/release.yaml (ou o contrário) — o release_id do pacote deixa de casar com o do serviço, e a identificação da release no log e no /whoami mente.
• Copiar descritores para src/main/resources — duas cópias, e um dia elas divergem. Aponte o <resources> para a raiz do módulo.
• -DskipTests como rotina — o gate local é o que impede o defeito de chegar ao cluster; pule só quando já rodou.
• Deixar dependência nova sem versão no POM do pai — o serviço não escolhe versão de terceiro: quem fixa é o console-service-parent.
• Commitar target/ — artefato de build não entra no repositório.