🚀 Zure Maven Proiektuak Hurrengo Mailara Eramateko 5 Aholku Zehatz

Kaixo berriro! 👋 Aurreko artikuluan Maven-en bizi-zikloaren oinarriak ikusi genituen. Baina oinarriak menperatu ondoren, hurrengo pausoa benetako arazoei aurre egiteko tresnak eta teknikak ezagutzea da: mendekotasun-gatazkak, bertsioen kudeaketa kaotikoa, ingurune desberdinetarako eraikuntzak, etab.

Artikulu honetan, zure pom.xml fitxategiak garbiagoak, zure eraikuntzak sendoagoak eta zure lana profesionalagoa bihurtuko duten bost aholku praktiko partekatuko ditut zurekin. Goazen horiek ikustera!

---

1. Aholkua: Menperatu mendekotasunen infernua maven-enforcer-plugin-arekin

Arazoa: "Mendekotasunen infernua" (dependency hell) deitzen zaion egoera oso ohikoa da. Zure proiektuak A liburutegiaren 2.0 bertsioa behar du, baina aldi berean, B liburutegiaren menpe dago, eta B liburutegi honek A liburutegiaren 1.5 bertsioa behar du. Zein bertsio erabiliko da azkenean? Gatazka hauek ustekabeko erroreak sor ditzakete exekuzio-garaian.

Irtenbidea: Maven Enforcer Plugin-a zure eraikuntzaren "zaindari" gisa jokatzen duen tresna indartsua da. Arau multzo bat konfigura dezakezu zure proiektuak bete behar dituen baldintzak ziurtatzeko.

Adibidea: Arau erabilienetako bat requireUpperBoundDeps da. Arau honek mendekotasun-zuhaitz osoa egiaztatzen du eta, gatazka bat aurkituz gero, zuzenean deklaratutako bertsioa baino bertsio zaharrago bat erabiltzen saiatzen bada, eraikuntzak huts egingo du.

XML

 

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-enforcer-plugin</artifactId>
            <version>3.4.1</version>
            <executions>
                <execution>
                    <id>enforce-versions</id>
                    <goals>
                        <goal>enforce</goal>
                    </goals>
                    <configuration>
                        <rules>
                            <requireUpperBoundDeps/>
                        </rules>
                    </configuration>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

Onura: Zure eraikuntzak deterministagoak bihurtzen dira eta ustekabeko liburutegi-bertsioek eragindako errore sotilak saihesten dituzu.

---

2. Aholkua: Sinplifikatu bertsioen kudeaketa BOM batekin (Bill of Materials)

Arazoa: Spring Boot edo Jakarta EE bezalako framework handi batekin lan egiten duzunean, modulu asko kudeatu behar dituzu (spring-boot-starter-web, spring-boot-starter-data-jpa, etab.). Guztiak bertsio bateragarriak direla ziurtatzea buruhauste bat izan daiteke, eta bakoitzaren bertsioa pom.xml-an deklaratzea neketsua eta akatsetarako joera duena da.

Irtenbidea: BOM (Bill of Materials) kontzeptua erabiltzea. BOM bat artefaktu multzo baten bertsioak zentralizatzen dituen pom.xml fitxategi berezi bat da.

Nola erabili: BOM-a inportatzen duzu zure <dependencyManagement> atalean, import esparruarekin. Hori egin ondoren, banakako mendekotasunak bertsiorik zehaztu gabe deklara ditzakezu. Maven BOM-etik bertsio zuzena eta bateragarria lortzeaz arduratuko da.

XML

 

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <version>3.3.4</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

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

Onura: pom.xml garbiagoa, framework-moduluen arteko bateragarritasun bermatua eta eguneratze errazak (bertsioa leku bakarrean aldatu besterik ez duzu).

---

3. Aholkua: Ulertu Mendekotasun-esparruak (scope)

Arazoa: Garatzaile askok lehenetsitako esparrua (compile) erabiltzen dute mendekotasun guztietarako. Horrek beharrezkoak ez diren liburutegiak dituzten pakete (JAR/WAR) handiegiak sor ditzake.

Irtenbidea: Esparru garrantzitsuenak ezagutzea eta zuzen erabiltzea.

• compile: Lehenetsia. Mendekotasuna konpilaziorako behar da eta azken paketean sartzen da.
• provided: Mendekotasuna konpilaziorako behar da, baina exekuzio-inguruneak "eskainiko" du (adibidez, Tomcat bezalako web zerbitzari batek Servlet API-a eskaintzen du). Hau funtsezkoa da paketearen tamaina murrizteko.
• runtime: Ez da konpilaziorako behar, baina exekuzio-garaian beharrezkoa da (adibidez, JDBC driver bat).
• test: Probak konpilatzeko eta exekutatzeko bakarrik behar da (adibidez, JUnit, Mockito). Ez da azken paketean sartzen.

Onura: Hedapen-pakete txikiagoak eta eraginkorragoak sortzen dituzu, eta proiektuaren classpath-a garbiago mantentzen duzu.

---

4. Aholkua: Gatazkak araztu dependency:tree-rekin

Arazoa: Zure eraikuntzak huts egiten du edo errore arraro bat duzu exekutatzean. Mendekotasun iragankor (transitive dependency) baten gatazka bat dela susmatzen duzu, baina ez dakizu nondik datorren. Nola ikusi argazki osoa?

Irtenbidea: Maven Dependency Plugin-a eta bere helburu erabilgarriena: dependency:tree.

Nola erabili: Exekutatu komando sinple hau:

Bash

 

mvn dependency:tree

Komando honek zure proiektuaren mendekotasun guztien zuhaitz hierarkiko argi bat inprimatuko du, iragankorrak barne. Gatazkak esplizituki markatuko ditu, zein liburutegik zein bertsio ekarri duen erakutsiz.

Onura: Zure proiektuaren mendekotasunen X izpien argazki bat bezalakoa da. Bertsio-gatazkak araztea izugarri azkarra eta zuzena bihurtzen du.

---

5. Aholkua: Kudeatu ingurune desberdinak Profilekin (profiles)

Arazoa: Zure aplikazioak konfigurazio desberdinak behar ditu garapenerako (dev), probetarako (qa) eta produkziorako (prod). Adibidez, datu-basearen URLa desberdina da ingurune bakoitzean. Nola kudeatu hau eraikuntza bakoitzerako fitxategiak eskuz editatu gabe?

Irtenbidea: Maven Profilak (<profiles>) erabiltzea. Profil bat baldintza jakin batzuetan aktiba daitekeen konfigurazio-balio multzo bat da.

Nola erabili: pom.xml-an dev eta prod profilak defini ditzakezu, bakoitzak propietate desberdinak ezarriz. Gero, profil bat komando-lerrotik aktibatu dezakezu -P banderarekin.

XML

 

<profiles>
    <profile>
        <id>dev</id>
        <properties>
            <database.url>jdbc:mysql://localhost/devdb</database.url>
        </properties>
    </profile>
    <profile>
        <id>prod</id>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
        <properties>
            <database.url>jdbc:mysql://10.0.0.1/proddb</database.url>
        </properties>
    </profile>
</profiles>

Bash

 

# Produkzioko profila erabiliz paketatzea
mvn package -Pprod

Onura: Ingurune desberdinetarako konfigura daitekeen eraikuntza-prozesu estandarizatu eta errepikagarri bat sortzeko aukera ematen du. CI/CD praktika onen zutabeetako bat da.

---

Amaiera: pom.xml fitxategitik haratago

Aholku hauek (Enforcer, BOM, Scopes, Dependency Tree, Profiles) Maven oinarrizko mailan erabiltzetik modu profesionalean erabiltzera pasatzeko gakoak dira. Teknika hauek aplikatuz, Java proiektu sendoagoak, mantentze errazagokoak eta profesionalagoak eraiki ahal izango dituzu. Zure pom.xml fitxategia ez da gehiago magia beltzeko kutxa bat izango, baizik eta zure kontrolpean dagoen tresna indartsu bat.