Introdução
A história da construção de software é uma jornada de trabalho manual e propensa a erros para sistemas automatizados e inteligentes. Antes de existirem ferramentas especializadas, os próprios desenvolvedores eram "construtores de programas", costurando códigos usando comandos de shell brutos. Caso prefira, voce pode ler este texto em Ingles
A Era Da Compilação Manual (Pre-2000)
Nos primeiros dias de Java, construir um projeto significava executar o compilador manualmente(javac). Se você tivesse 4 arquivos e um par de bibliotecas externas (armazenadas como arquivos JAR), seu "processo de construção" era uma corda longa e frágil em um terminal.
Imagine que você tem Main.java, Utils.java, Data.java e Config.java, e você precisa das bibliotecas json.jar e log4j.jar. Você teria que digitar:
# Compiling manually
javac -cp "lib/json.jar:lib/log4j.jar" -d bin src/*.java
# Packaging into a JAR manually
jar cvf MyProgram.jar -C bin .Se você perdeu um ponto e vírgula ou um caminho de arquivo, a coisa toda colpsava. Para corrigir isso, os desenvolvedores escreveram Makefiles (emprestados de C++), mas estes eram dependentes da plataforma e lutavam com as estruturas de diretórios de Java.
Apache Ant: O primeiro verdadeiro construtor de Java (2000)
Ant ("Another Neat Tool" ("Outra ferramenta legal")) substituiu os scripts de shell bagunçados por XML. Introduziu "Targets"("Alvos") (como clean(limpo), compile(compilar) e jar). No entanto, Ant não tinha "cérebro" sobre bibliotecas, você ainda tinha que baixar manualmente cada arquivo JAR e colocá-lo em uma pasta /lib.
Exemplo build.xml:
<project name="MyProject" default="compile">
<target name="compile">
<mkdir dir="build/classes"/>
<javac srcdir="src" destdir="build/classes">
<classpath>
<fileset dir="lib" includes="**/*.jar"/>
</classpath>
</javac>
</target>
<target name="jar" depends="compile">
<jar destfile="MyProgram.jar" basedir="build/classes"/>
</target>
</project>Como instalar
Para instalar ant, primeiro vá ao seu site para fazer o download. Você pode seguir o passo-a-passo com mais detalhes se você quiser aqui, mas é basicamente uma questão de descompactar o arquivo que você acabou de baixar, copiar a pasta para algum lugar seu usuário tem acesso de leitura+escrita(eu geralmente tenho uma pasta chamada .apps no meu /home/meu-usuário e lá eu crio outra pasta chamada builders(construtores)), então abrir o arquivo ~/.bashrc ou ~/.zshrc, ir para o final do arquivo e adicionar essas duas alterações:
# File ~/.bashrc or ~/.zshrc
# ..... lots of lines
export ANT_HOME=~/.apps/builders/ant_folder
export PATH=$PATH:$ANT_HOME/binSe já existir export PATH=..., certifique-se de não mudar o que já está lá, mas apenas adicionar no final dele :$ANT_HOME/bin, e não se esqueça do : antes $ANT_HOME
Agora vá até o terminal e digite
ant --versionSe tudo correr bem, deverá ver a versão da formiga no seu terminal.
Todas essas instruções são para usuários de Linux/Mac, mas também podem funcionar para Windows. A diferença é onde você cria a variável de ambiente ANT HOME e onde você e como você a adiciona ao PATH.
Contêineres
O desenvolvimento da Web estava se tornando uma grande coisa na época e mesmo que Ant veio salvar desenvolvedores em relação à construção e empacotamento de seus projetos, ajudando os desenvolvedores a se concentrar mais no negócio principal do que como implantá-lo, ainda havia um pequeno problema: Dependências Externas.
Como uma aplicação web consiste em um aplicativo rodando em um servidor que outras pessoas acessarão através de vários meios (na maioria das vezes, um navegador web), não se poderia descuidadamente subir código para um servidor, e com Ant você tinha que baixar manualmente todas as bibliotecas externas que sua aplicação dependia, abrindo muitas possibilidades de código malicioso.
Para ajudar a melhorar isso, empresas que trabalham para facilitar o desenvolvimento da web tiveram uma ideia brilhante: Contêineres. Não confunda com docker. A ideia era que eles lhe dariam uma aplicação web meio cozida, preenchida com o mínimo de bibliotecas para iniciar uma aplicação web simples ou mesmo intermediária (o que quer que isso signifique, eu meio que acabei de inventar este termo).
Você deve ter ouvido falar desses contêineres, eles ainda vivem entre nós: [Jboss] (https://www.jboss.org/), [Tomcat] (https://tomcat.apache.org/), [Glassfish] (https://glassfish.org/), [Websphere] (https://www.ibm.com/products/websphere-aplication-servidor). Você ainda tinha que baixar manualmente quaisquer outras dependências externas que você poderia ter, como log4j, talvez uma implementação jsf melhor (como richfaces ou primefaces), etc, mas era um pouco mais seguro agora como o número de coisas que você teria que baixar era menor.
Apache Maven: Convenção sobre Configuração (2004)
Os contêineres pareciam ter melhorado a gestão e diminuído a necessidade de baixar muitas dependências no início, mas com o tempo, muitas novas bibliotecas para ajudar a diminuir o tempo de desenvolvimento foram criados trazendo o caos de volta, então veio [Maven] (https://maven.apache.org/)
Maven foi uma revolução. Introduziu dois conceitos de mudança mundial: uma Disposição padrão de pastas (todos colocam código em src/main/java se fosse uma aplicação java, src/main.scala para uma aplicação scala e assim por diante) e Gestão de Dependência Centralizada chamada Repositório Maven. Você não possui mais arquivos JAR, você os lista em um arquivo pom.xml, e Maven baixa para você.
Exemplo pom.xml:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>my-app</artifactId>
<version>1.0</version>
<packaging>jar</packaging>
<dependencies>
<dependency>
<groupId>org.json</groupId>
<artifactId>json</artifactId>
<version>20231013</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>3.3.0</version>
</plugin>
</plugins>
</build>
</project>Essas duas libs então seriam baixadas em uma pasta fora do seu projeto (geralmente em ~/.m2), e só seriam adicionadas ao seu projeto se você precisasse empacotar o aplicativo tornando-o uma pasta compartilhada para quantas aplicações você quisesse.
Como instalar
Para instalar Maven, vá ao site deles para fazer o download: Aqui Você pode seguir o passo-a-passo com mais detalhes se você quiser aqui, mas é basicamente uma questão de descompactar o arquivo que você acabou de baixar, copiar a pasta para algum lugar onde seu usuário tenha acesso de leitura+escrita(Eu geralmente tenho uma pasta chamada .apps no meu /home/my-user e lá eu crio outra pasta chamada builders), então abrir o arquivo ~/.bashrc ou ~/.zshrc, ir para o final do arquivo e adicionar estas duas alterações:
# File ~/.bashrc or ~/.zshrc
# ..... lots of lines
export MAVEN_HOME=~/.apps/builders/maven_folder
export PATH=$PATH:$MAVEN_HOME/binSe já existir export PATH=..., certifique-se de não mudar o que já está lá, mas apenas adicionar no final dele :$MAVEN_HOME/bin, e não se esqueça do : antes $MAVEN_HOME
Agora vá até o terminal e digite:
mvn --versionSe tudo correr bem, deverá ver a versão do Maven no seu terminal.
Todas essas instruções são para usuários Linux/Mac, mas podem funcionar para Windows também. A diferença é onde você cria a variável de ambiente MAVEN_HOME e onde você e como você a adiciona ao PATH.
Gradle: Desempenho e flexibilidade (2007)
À medida que os projetos cresciam, o XML do Maven ficava inchado e rígido. Gradle chegou, trocando XML por um DSL Groovy (ou Kotlin). Combinou a flexibilidade de Ant com o gerenciamento de dependência de Maven, enquanto acrescentava "Construções Incrementais" para economizar tempo apenas compilando o que mudou.
Exemplo build.gradle:
plugins {
id 'java'
}
dependencies {
implementation 'org.json:json:20231013'
testImplementation 'org.junit.jupiter:junit-jupiter:5.9.2'
}
jar {
archiveBaseName = 'my-gradle-app'
manifest { attributes 'Main-Class': 'com.example.Main' }
}Assim como Maven, ele usa o mesmo repositório onde os jars são armazenados, o Repositório Maven, mas ao contrário do Maven que só suporta linguagens da JVM, você pode usar Gradle para linguagens como C e C++, Python, Javascript, etc.
Como instalar
Para instalar Gradle, vá ao site deles para fazer o download: Aqui Você pode seguir o passo-a-passo com mais detalhes se você quiser aqui, mas é basicamente uma questão de descompactar o arquivo que você acabou de baixar, copiar a pasta para algum lugar onde seu usuário tenha acesso de leitura+escrita(Eu geralmente tenho uma pasta chamada .apps no meu /home/my-user e lá eu crio outra pasta chamada builders), então abrir o arquivo ~/.bashrc ou ~/.zshrc, ir para o final do arquivo e adicionar estas duas alterações:
# File ~/.bashrc or ~/.zshrc
# ..... lots of lines
export GRADLE_HOME=~/.apps/builders/gradle_folder
export PATH=$PATH:$GRADLE_HOME/binSe já existir export PATH=..., certifique-se de não mudar o que já está lá, mas apenas adicionar no final dele :$GRADLE_HOME/bin, e não se esqueça do : antes $GRADLE_HOME
Agora vá até o terminal e digite:
gradle -versionSe tudo correr bem, deverá ver a versão do Gradle no seu terminal.
Todas essas instruções são para usuários Linux/Mac, mas podem funcionar para Windows também. A diferença é onde você cria a variável de ambiente GRADLE_HOME e onde você e como você a adiciona ao PATH.
SBT: O Padrão Scala (2008)
Para o ecossistema Scala, SBT (Scala Build Tool) tornou-se o padrão. É altamente otimizado para as necessidades complexas da compilação Scala, mas também lida com Java. Ele usa o plugin sbt-assembly para criar "Fat JARs" (um JAR contendo todo o seu código e todas as suas dependências).
Exemplo build.sbt:
name := "MySbtProject"
version := "1.0"
scalaVersion := "2.13.12"
libraryDependencies += "org.json" % "json" % "20231013"
// Assembly plugin settings (requires project/plugins.sbt: addSbtPlugin("com.eed3si9n" % "sbt-assembly" % "2.1.1"))
assembly / mainClass := Some("com.example.Main")
assembly / assemblyJarName := "my-fat-app.jar"Como instalar
Para instalar SBT, vá ao site deles para fazer o download: Aqui Você pode seguir o passo-a-passo com mais detalhes se você quiser aqui, mas é basicamente uma questão de descompactar o arquivo que você acabou de baixar, copiar a pasta para algum lugar onde seu usuário tenha acesso de leitura+escrita(Eu geralmente tenho uma pasta chamada .apps no meu /home/my-user e lá eu crio outra pasta chamada builders), então abrir o arquivo ~/.bashrc ou ~/.zshrc, ir para o final do arquivo e adicionar estas duas alterações:
# File ~/.bashrc or ~/.zshrc
# ..... lots of lines
export SBT_HOME=~/.apps/builders/sbt_folder
export PATH=$PATH:$SBT_HOME/binSe já existir export PATH=..., certifique-se de não mudar o que já está lá, mas apenas adicionar no final dele :$SBT_HOME/bin, e não se esqueça do : antes $SBT_HOME
Agora vá até o terminal e digite:
sbt -versionSe tudo correr bem, deverá ver a versão do Gradle no seu terminal.
Todas essas instruções são para usuários Linux/Mac, mas podem funcionar para Windows também. A diferença é onde você cria a variável de ambiente SBT_HOME e onde você e como você a adiciona ao PATH.
Bonus track
É digno de mencionar que eu foquei em construtores de linguagem JVM, mesmo que Gradle possa trabalhar com linguagens de fora da JVM, este post é essencialmente uma história simples e tutorial para linguagens JVM (como eu repeti 3 vezes por este tempo). Existem outros construtores para outras linguagens, como cargo para Rust, Webpack para [javascript](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Language overview), CMake para C, C++ e assim por diante.
Mesmo se eu quisesse listar todos os construtores aqui, seria uma lista enorme. Então este é apenas um pequeno subconjunto, mas eu acho que é o suficiente para você ter a idéia. Saber escrever um programa é apenas o começo da história, construí-lo mais tarde para entregar e implantar é apenas mais um capítulo disso e está sempre evoluindo.