Maven vs Gradle — budowanie#

Każdy projekt Java potrzebuje narzędzia builda — zarządza zależnościami, kompiluje, testuje i pakuje. W ekosystemie dominują dwa: Maven (deklaratywny, XML) i Gradle (elastyczny, skrypt Kotlin/Groovy). Ta lekcja porównuje je i pokazuje nasze konwencje.

Maven — deklaratywny standard#

Maven opisuje projekt w pom.xml i działa według sztywnego cyklu życia (validate → compile → test → package → install → deploy). Prosty, przewidywalny.

<project>
  <groupId>com.professnet.zeus</groupId>
  <artifactId>inventory-service</artifactId>
  <version>1.0.0</version>

  <properties>
    <maven.compiler.release>21</maven.compiler.release>
  </properties>

  <dependencies>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
  </dependencies>
</project>

mvn clean verify       # kompilacja + testy + sprawdzenia
mvn package            # zbuduj artefakt (jar)

Gradle — elastyczny i szybki#

Gradle używa skryptu (preferujemy Kotlin DSL — build.gradle.kts). Jest szybszy dzięki cache builda i buildowi przyrostowemu, ale wymaga więcej dyscypliny.

plugins {
    java
    id("org.springframework.boot") version "3.3.0"
}

java {
    toolchain { languageVersion = JavaLanguageVersion.of(21) }
}

dependencies {
    implementation("org.springframework.boot:spring-boot-starter-web")
    testImplementation("org.springframework.boot:spring-boot-starter-test")
}

./gradlew build        # kompilacja + testy
./gradlew bootJar      # artefakt Spring Boot

Porównanie#

Cecha	Maven	Gradle
Konfiguracja	XML, deklaratywny	Kotlin/Groovy, programowalny
Krzywa wejścia	łagodna	stroma
Szybkość	wolniejszy	szybszy (cache, incremental)
Elastyczność	ograniczona	bardzo duża
Czytelność dla nowych	wysoka	zależy od dyscypliny

Standard ProfessNet: dla prostych, typowych serwisów wybieramy Maven (przewidywalność, niski próg wejścia). Dla dużych, wielomodułowych projektów i monorepo, gdzie liczy się czas builda — Gradle z Kotlin DSL.

Wrapper — powtarzalny build#

Zawsze commitujemy wrapper (mvnw / gradlew). Gwarantuje, że wszyscy budują tą samą wersją narzędzia, niezależnie od tego, co mają na maszynie.

./mvnw clean verify        # nie 'mvn' — wrapper z repo
./gradlew build            # nie 'gradle'

Standard ProfessNet: w CI i lokalnie używamy wrappera, nie globalnej instalacji. Wersję narzędzia przypina .mvn/wrapper lub gradle/wrapper/gradle-wrapper.properties.

Zależności — zakresy i BOM#

Wersje powiązanych bibliotek spinamy przez BOM (np. Spring Boot dependencies), żeby nie zarządzać każdą wersją z osobna.

Zakres (Maven / Gradle)	Znaczenie
compile / implementation	dostępna w kompilacji i runtime
provided / compileOnly	tylko kompilacja (np. Lombok)
test / testImplementation	tylko testy

Wskazówka: nie mieszaj wersji ręcznie z BOM-em. Jeśli BOM podaje wersję, nie nadpisuj jej bez powodu — to źródło konfliktów na classpath.

---

Maven dla prostoty, Gradle dla skali — oba z wrapperem i spójnym zarządzaniem zależnościami. Wybór narzędzia ustalamy raz na projekt, a potem trzymamy się go konsekwentnie.