Maven আর Gradle — বিল্ড আর dependency সামলানো

১ · হাতে build-এর যন্ত্রণা — কেন build tool দরকার

এতক্ষণ এই কোর্সের প্রায় সব কোড ছিল এক ফাইলে, শুধু JDK দিয়ে। পর্ব ২২-এর “হিসাব খাতা”-তে ফাইল হলো নয়টি, তখন লিখেছিলেন javac -d out *.java. এটুকু হাতে চলে। কিন্তু একটি আসল প্রজেক্টের চেহারা অন্যরকম: কয়েকশো সোর্স ফাইল, টেস্টের আলাদা ফাইল, আর কয়েক ডজন বাইরের library — JSON-এর জন্য Jackson (পর্ব ৩৯), টেস্টের জন্য JUnit (পর্ব ৪৭), লগ লেখার জন্য একটি, ডেটাবেসের জন্য আরেকটি।

প্রতিটি library আসে একটি JAR ফাইল হিসেবে — অনেকগুলো .class ফাইলের একটি zip. এখন হাতে কাজটা করে দেখা যাক:

# ১. প্রতিটি JAR ওয়েবসাইট থেকে নিজে নামিয়ে lib ফোল্ডারে রাখুন
# ২. তারপর compile — প্রতিটি JAR-এর নাম classpath-এ
javac -cp "lib/jackson-databind-2.17.2.jar:lib/jackson-core-2.17.2.jar:lib/jackson-annotations-2.17.2.jar" -d out $(find src -name "*.java")

# ৩. টেস্ট compile আর চালানো — আরও কয়েকটি JAR
# ৪. চালানো — আবার একই লম্বা classpath (Windows-এ : এর বদলে ;)
java -cp "out:lib/jackson-databind-2.17.2.jar:lib/jackson-core-2.17.2.jar:lib/jackson-annotations-2.17.2.jar" com.abcltech.hisab.Main

লক্ষ করুন, আপনি চেয়েছিলেন শুধু Jackson, অথচ তিনটি JAR লাগল। কারণ jackson-databind নিজেই আরও দুটি library-র ওপর নির্ভর করে। এদের বলে transitive dependency — আপনার dependency-র dependency. বড় library-তে এই গাছ কয়েক স্তর গভীর হয়, আর কোনটার কোন version লাগবে তা হাতে বের করা প্রায় অসম্ভব।

JAR hell — classpath-এর ক্রমে লুকানো বিপদ

ধরুন lib ফোল্ডারে ভুল করে একটি library-র দুটি version রয়ে গেছে, অথবা দুটি library একই তৃতীয় library-র আলাদা version চায়। JVM classpath-এ বাঁ থেকে ডানে খোঁজে, আর একটি class প্রথম যেখানে পায়, সেটাই নেয়। আপনার কোড compile হয়েছিল নতুন version দেখে, কিন্তু চলার সময় classpath-এ আগে পড়ল পুরোনোটা — যেখানে একটি method নেই। compile-এ কোনো ভুল ধরা পড়েনি, ধরা পড়ল চলার মাঝখানে:

Exception in thread "main" java.lang.NoSuchMethodError: 'void Lib.newMethod()'
	at Main.main(Main.java:1)

আর একটি JAR পুরোপুরি বাদ পড়লে আসে java.lang.NoClassDefFoundError: Lib, যার নিচে Caused by: java.lang.ClassNotFoundException: Lib. এই দুই ধরনের সমস্যার ডাকনাম JAR hell. এর সবচেয়ে খারাপ দিক: আপনার মেশিনে চলে, সহকর্মীর মেশিনে চলে না — কারণ দুজনের lib ফোল্ডার আলাদা।

২ · Maven-এর চিন্তা — রীতি মানলে কম লিখতে হয়

Maven-এর মূল দর্শন convention over configuration — পর্ব ৪৫-এর ভাবনার প্রশ্নে যা দেখেছেন। Ant-এ প্রতিটি build ফাইলে লিখতে হতো সোর্স কোথায়, টেস্ট কোথায়, ফল কোথায় যাবে। Maven বলল: সবাই একই কাঠামো মানুক, তাহলে এসব লিখতেই হবে না। এই কাঠামো এখন এত প্রচলিত যে Gradle-ও ডিফল্টে এটাই মানে।

hisab-khata/
├── pom.xml                         ← প্রজেক্টের বর্ণনা (রেসিপি কার্ড)
├── src/
│   ├── main/
│   │   ├── java/                   ← আসল কোড
│   │   │   └── com/abcltech/hisab/
│   │   │       ├── Main.java
│   │   │       ├── Expense.java
│   │   │       └── ExpenseBook.java
│   │   └── resources/              ← কোডের সাথে যাওয়া ফাইল (app.properties, লোগো)
│   └── test/
│       ├── java/                   ← টেস্ট কোড (পর্ব ৪৭)
│       │   └── com/abcltech/hisab/ExpenseBookTest.java
│       └── resources/              ← শুধু টেস্টে লাগে এমন ফাইল
└── target/                         ← Maven-এর তৈরি সব কিছু (git-এ রাখবেন না)
    ├── classes/
    └── hisab-khata-1.0.0-SNAPSHOT.jar

তিনটি জিনিস খেয়াল করুন। প্রথমত, আসল কোড আর টেস্ট কোড আলাদা গাছে — টেস্ট কখনো চূড়ান্ত JAR-এ ঢোকে না। দ্বিতীয়ত, java/-এর নিচে ফোল্ডারগুলো package-এর নাম অনুযায়ী: com.abcltech.hisab মানে com/abcltech/hisab/. পর্ব ২২-এ সব ফাইল নামহীন default package-এ ছিল; আসল প্রজেক্টে প্রতিটি class একটি package-এ থাকে, আর প্রতিটি ফাইলের প্রথম লাইন package com.abcltech.hisab;. তৃতীয়ত, target/ পুরোটাই তৈরি করা জিনিস — মুছে ফেললেও mvn package আবার বানিয়ে দেবে। তাই .gitignore-এ target/ লেখা থাকে।

প্রতিটি প্রজেক্টের ঠিকানা — groupId:artifactId:version

Maven-এর জগতে প্রতিটি প্রজেক্ট আর প্রতিটি library-র একটি অনন্য ঠিকানা আছে, যাকে বলে coordinates, সংক্ষেপে GAV:

লেখার সময় এরা কোলন দিয়ে জোড়া হয়: com.fasterxml.jackson.core:jackson-databind:2.17.2. এই এক লাইন দেখে Maven বা Gradle পৃথিবীর যেকোনো জায়গা থেকে ঠিক সেই JAR খুঁজে আনতে পারে। নতুন Maven প্রজেক্ট সাধারণত বানানো হয় IntelliJ-এর New Project-এ Build system “Maven” বেছে, অথবা Spring Boot-এর জন্য start.spring.io থেকে — দুটিই ওপরের কাঠামো আর একটি pom.xml তৈরি করে দেয়।

৩ · pom.xml-এর ভেতরে — “হিসাব খাতা”-কে Maven প্রজেক্ট বানানো

Maven প্রজেক্টের হৃদয় pom.xml (POM = Project Object Model). এখানে “হিসাব খাতা”-র জন্য একটি সম্পূর্ণ pom দেওয়া হলো — খরচের তালিকা JSON ফাইলে সেভ করতে Jackson আর টেস্টের জন্য JUnit 5. এটা XML ফাইল, Java নয়, তাই চালানোর বোতাম নেই। সংস্করণ নম্বরগুলো উদাহরণ — সর্বশেষ সংস্করণ Maven Central-এ দেখুন।

<?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">
    <modelVersion>4.0.0</modelVersion>

    <!-- ১. এই প্রজেক্টের ঠিকানা -->
    <groupId>com.abcltech</groupId>
    <artifactId>hisab-khata</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <packaging>jar</packaging>

    <!-- ২. সব জায়গায় ব্যবহারের মান -->
    <properties>
        <maven.compiler.release>21</maven.compiler.release>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <jackson.version>2.17.2</jackson.version>
    </properties>

    <!-- ৩. বাইরের library -->
    <dependencies>
        <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-databind</artifactId>
            <version>${jackson.version}</version>
        </dependency>
        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter</artifactId>
            <version>5.10.3</version>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <!-- ৪. plugin-এর সংস্করণ নির্দিষ্ট করা -->
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>3.2.5</version>
            </plugin>
        </plugins>
    </build>
</project>

অংশ ধরে ধরে দেখা যাক:

• ঠিকানা আর packaging: packaging বলে কী বানাতে হবে — jar (ডিফল্ট), war (পুরোনো ধাঁচের ওয়েব সার্ভারের জন্য), অথবা pom (শুধু অন্য প্রজেক্টের অভিভাবক, অংশ ৮-এ)। version-এর শেষে -SNAPSHOT মানে “কাজ চলছে” — অংশ ৪-এ বিস্তারিত।
• properties: নিজের নাম দিয়ে মান রাখা যায় (jackson.version) আর ${...} দিয়ে বারবার ব্যবহার করা যায় — Jackson-এর কয়েকটি অংশ একসাথে লাগলে এক জায়গায় version বদলালেই হয়। কিছু নাম Maven নিজে চেনে: maven.compiler.release হলো javac-এর --release 21, মানে Java 21-এর ভাষা ও API. আর sourceEncoding UTF-8 না দিলে বাংলা লেখা থাকা সোর্স ফাইলে Windows-এ সমস্যা হতে পারে, Maven সতর্কও করে।
• dependencies: প্রতিটি library-র GAV. Jackson-এর বাকি দুটি অংশ (core, annotations) লিখতে হয়নি — Maven নিজেই খুঁজে নেবে।
• build/plugins: Maven নিজে প্রায় কিছুই করে না; compile করে compiler plugin, টেস্ট চালায় surefire plugin. এদের ডিফল্ট সংস্করণ আপনার Maven সংস্করণের ওপর নির্ভর করে, তাই পেশাদার প্রজেক্টে plugin-এর সংস্করণও লিখে দেওয়া হয় — নাহলে দুই মেশিনে দুই রকম build হতে পারে।

scope — dependency কোথায় কোথায় লাগবে

সব library সব জায়গায় লাগে না। JUnit লাগে শুধু টেস্ট compile আর চালানোর সময়; চূড়ান্ত প্রোগ্রামে এর কোনো কাজ নেই। scope দিয়ে Maven-কে এটা বলা হয়:

runtime-এর যুক্তিটা সুন্দর: আপনার কোড লেখা হয় java.sql-এর interface দিয়ে (পর্ব ২১-এর “interface-এ প্রোগ্রাম করুন”), তাই compile-এর সময় MySQL বা PostgreSQL driver-এর কোনো class দরকার নেই; শুধু চলার সময় একটি implementation থাকতে হবে। scope দিয়ে এই নকশা build-এ পাহারা পায় — ভুল করে driver-এর class সরাসরি ব্যবহার করলে compile-ই হবে না।

৪ · lifecycle — phase, plugin আর goal

Maven-এ আপনি সাধারণত বলেন না “compile করো, তারপর টেস্ট চালাও”। আপনি বলেন কোন পর্যন্ত যেতে চান। Maven-এর একটি নির্দিষ্ট ধাপের ক্রম আছে, যাকে বলে build lifecycle. মূল ধাপগুলো (phase):

validate → compile → test → package → verify → install → deploy

নিয়ম একটাই: কোনো phase চাইলে তার আগের সব phase ক্রমে চলবে। mvn package মানে validate, compile, test, তারপর package. আর phase নিজে কোনো কাজ করে না — এটা শুধু একটি নাম, একটি “খুঁটি”। আসল কাজ করে plugin-এর goal, যা কোনো phase-এ বাঁধা থাকে। jar packaging-এ Maven নিজেই এই বাঁধন করে দেয়। ধাপে ধাপে দেখুন:

$ mvn package
[INFO] Building hisab-khata 1.0.0-SNAPSHOT
pom.xml পড়া, GAV আর প্রয়োজনীয় তথ্য আছে কি না দেখা,
দরকার হলে dependency আর plugin নামানো (প্রথমবার)

[INFO] --- resources:3.3.1:resources (default-resources) @ hisab-khata ---
[INFO] --- compiler:3.13.0:compile (default-compile) @ hisab-khata ---
[INFO] Compiling 9 source files with javac [debug release 21] to target/classes
src/main/resources → target/classes (কপি)
src/main/java → target/classes (*.class)

[INFO] --- compiler:3.13.0:testCompile (default-testCompile) @ hisab-khata ---
[INFO] --- surefire:3.2.5:test (default-test) @ hisab-khata ---
[INFO] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0
টেস্ট classpath = target/classes + target/test-classes
                + compile আর test scope-এর সব JAR

[INFO] --- jar:3.4.2:jar (default-jar) @ hisab-khata ---
[INFO] Building jar: target/hisab-khata-1.0.0-SNAPSHOT.jar
[INFO] BUILD SUCCESS
JAR-এ শুধু target/classes — টেস্ট আর dependency নেই

mvn verify    ← package + integration test, মান-যাচাই
mvn install   ← JAR কপি হয় ~/.m2/repository-তে
mvn deploy    ← দূরের repository-তে প্রকাশ
mvn clean package ← আগে target/ মুছে নতুন করে

local repository আর Maven Central

Maven JAR নামায় কোথা থেকে? ডিফল্টে Maven Central থেকে — Java জগতের সবচেয়ে বড় উন্মুক্ত library-ভান্ডার। নামানো প্রতিটি JAR রাখা হয় আপনার কম্পিউটারের local repository-তে, ডিফল্টে ~/.m2/repository (Windows-এ C:\Users\<নাম>\.m2\repository). ঠিকানা GAV থেকেই তৈরি:

~/.m2/repository/com/fasterxml/jackson/core/jackson-databind/2.17.2/
    jackson-databind-2.17.2.jar
    jackson-databind-2.17.2.pom      ← এর নিজের dependency-র তালিকা
    jackson-databind-2.17.2.jar.sha1 ← যাচাইয়ের checksum

দ্বিতীয়বার build-এ Maven আর নামায় না, এখান থেকেই নেয়; আপনার দশটি প্রজেক্ট একই Jackson ব্যবহার করলে ডিস্কে কপি একটিই। লক্ষ করুন .pom ফাইলটি — প্রতিটি library-র নিজেরও একটি pom আছে, আর সেখান থেকেই Maven transitive dependency খুঁজে পায়। mvn install আপনার নিজের প্রজেক্টের JAR এই ফোল্ডারে রাখে, যাতে একই মেশিনের অন্য প্রজেক্ট সেটাকে dependency হিসেবে ব্যবহার করতে পারে।

SNAPSHOT, release আর semantic versioning

version-এর শেষে -SNAPSHOT থাকলে সেটা SNAPSHOT version — “এখনো তৈরি হচ্ছে, যেকোনো সময় বদলাবে”। Maven এমন dependency-র নতুন কপি মাঝে মাঝে আবার খোঁজে। 1.0.0-এর মতো release version-এর নিয়ম উল্টো: একবার প্রকাশ হলে আর কখনো বদলায় না। Maven Central-এ প্রকাশ করা release মুছে ফেলা বা বদলানো যায় না — এই অপরিবর্তনীয়তাই build-কে নির্ভরযোগ্য করে (ভাবনার প্রশ্ন ৩)। Maven Central SNAPSHOT গ্রহণই করে না।

বেশিরভাগ library semantic versioning মেনে চলার চেষ্টা করে: MAJOR.MINOR.PATCH. PATCH বাড়ে ভুল সংশোধনে (2.17.1 → 2.17.2), MINOR বাড়ে নতুন সুবিধা যোগ হলে কিন্তু পুরোনো কোড না ভেঙে (2.16 → 2.17), MAJOR বাড়ে যখন পুরোনো কোড ভাঙতে পারে (Jackson 2.x → 3.x, যেখানে package-এর নামই বদলেছে)। এটা একটি প্রতিশ্রুতি, আইন নয় — তাই MINOR আপগ্রেডের পরেও টেস্ট চালাতে হয়।

৫ · transitive dependency আর সংঘাত — nearest wins

“হিসাব খাতা”-য় আপনি লিখেছেন দুটি dependency. Maven আসলে কী কী নামাল, দেখার কমান্ড mvn dependency:tree. প্রত্যাশিত আউটপুট (সংক্ষেপে):

$ mvn dependency:tree
[INFO] com.abcltech:hisab-khata:jar:1.0.0-SNAPSHOT
[INFO] +- com.fasterxml.jackson.core:jackson-databind:jar:2.17.2:compile
[INFO] |  +- com.fasterxml.jackson.core:jackson-annotations:jar:2.17.2:compile
[INFO] |  \- com.fasterxml.jackson.core:jackson-core:jar:2.17.2:compile
[INFO] \- org.junit.jupiter:junit-jupiter:jar:5.10.3:test
[INFO]    +- org.junit.jupiter:junit-jupiter-api:jar:5.10.3:test
[INFO]    ...  (JUnit-এর আরও কয়েকটি অংশ, সবই test scope)

প্রতিটি লাইনের গঠন groupId:artifactId:packaging:version:scope, আর দাগগুলো গাছের শাখা। JUnit-এর নিচের সবকিছু test scope পেয়েছে — scope উত্তরাধিকারসূত্রেও যায়। এবার ধরুন “হিসাব খাতা” বড় হলো: মাসিক রিপোর্ট PDF-এ বানাতে একটি pdf-report library, আর খরচের সতর্কবার্তা পাঠাতে একটি sms-gateway library যোগ হলো (দুটিই উদাহরণের জন্য বানানো নাম)। দুটিই ভেতরে Jackson ব্যবহার করে — কিন্তু আলাদা version. classpath-এ একটি class-এর একটিই version থাকতে পারে, তাই Maven-কে বেছে নিতে হবে। এই বাছাইয়ের নিয়মকে বলে dependency mediation:

1hisab-khata:1.02+- pdf-report:3.03|  \- jackson-databind:2.15.04\- sms-gateway:1.25   \- http-client:4.16      \- jackson-databind:2.17.2

এই নিয়ম নিজে হাতে চালিয়ে দেখুন। নিচের প্রোগ্রাম একটি ছোট “dependency resolver”: প্রতিটি library-র pom একটি Map-এ রাখা, আর গাছটি স্তর ধরে পড়া হয় — পর্ব ৩২-এর Queue দিয়ে BFS. যে নাম প্রথমবার দেখা যায়, সেটাই জেতে; কারণ BFS-এ কাছের স্তর সবসময় আগে আসে।

import java.util.*;

record Dep(String name, String version) {
    @Override public String toString() { return name + ":" + version; }
}
record Step(Dep dep, int depth) {}

class Main {
    public static void main(String[] args) {
        Map<String, List<Dep>> poms = Map.of(                        // প্রতিটি library-র pom, শুধু খোঁজার জন্য
            "hisab-khata:1.0", List.of(new Dep("pdf-report", "3.0"), new Dep("sms-gateway", "1.2")),
            "pdf-report:3.0", List.of(new Dep("jackson-databind", "2.15.0")),
            "sms-gateway:1.2", List.of(new Dep("http-client", "4.1")),
            "http-client:4.1", List.of(new Dep("jackson-databind", "2.17.2")));
        Map<String, String> chosen = new LinkedHashMap<>();         // নাম -> বেছে নেওয়া version
        Deque<Step> queue = new ArrayDeque<>(List.of(new Step(new Dep("hisab-khata", "1.0"), 0)));
        while (!queue.isEmpty()) {                                   // BFS: কাছের স্তর আগে
            Step s = queue.poll();
            String pad = "[" + s.depth() + "] " + "  ".repeat(s.depth());
            String winner = chosen.putIfAbsent(s.dep().name(), s.dep().version());
            if (winner != null) { System.out.println(pad + s.dep() + "  (omitted: " + winner + " is nearer)"); continue; }
            System.out.println(pad + s.dep());
            for (Dep d : poms.getOrDefault(s.dep().toString(), List.of())) queue.add(new Step(d, s.depth() + 1));
        }
        chosen.remove("hisab-khata");
        System.out.println("classpath: " + chosen);
    }
}

dependencyManagement আর BOM — version এক জায়গায়

প্রতিটি সংঘাতে হাতে dependency যোগ করা ঝামেলার, আর সেই dependency আপনি সত্যিই সরাসরি ব্যবহার করেন না। পরিষ্কার উপায় হলো dependencyManagement: এখানে লেখা মানে “এই library যেখানেই আসুক — সরাসরি বা transitive — এই version-ই হবে”। এটা নিজে কোনো dependency যোগ করে না, শুধু version-এর সিদ্ধান্ত দেয়।

<dependencyManagement>
    <dependencies>
        <!-- BOM: Jackson-এর সব অংশের মিলিয়ে নেওয়া version-এর তালিকা -->
        <dependency>
            <groupId>com.fasterxml.jackson</groupId>
            <artifactId>jackson-bom</artifactId>
            <version>2.17.2</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

<dependencies>
    <dependency>   <!-- version লাগে না, BOM থেকে আসে -->
        <groupId>com.fasterxml.jackson.core</groupId>
        <artifactId>jackson-databind</artifactId>
    </dependency>
</dependencies>

BOM (Bill of Materials) হলো একটি বিশেষ pom, যার ভেতরে শুধু একটি dependencyManagement — কোন কোন অংশের কোন version একসাথে পরীক্ষা করা হয়েছে, তার তালিকা। scope import দিয়ে সেই তালিকা নিজের pom-এ টেনে আনা হয়। সবচেয়ে বড় উদাহরণ Spring Boot: এর BOM কয়েকশো library-র মিলিয়ে নেওয়া version ঠিক করে দেয়, তাই Spring Boot প্রজেক্টে Jackson, JUnit বা ডেটাবেস driver যোগ করতে সাধারণত version লিখতেই হয় না (পর্ব ৫০)। JUnit-এরও নিজস্ব junit-bom আছে। আরও দুটি হাতিয়ার জেনে রাখুন: কোনো transitive dependency একেবারে বাদ দিতে <exclusions>, আর Maven Enforcer plugin-এর dependencyConvergence নিয়ম, যা গাছে একই library-র দুটি version দেখলে build ব্যর্থ করে দেয় — সংঘাত নীরবে লুকিয়ে থাকতে পারে না।

৬ · Gradle — build-এর বর্ণনা কোড দিয়ে

Gradle একই সমস্যার আরেকটি সমাধান, ভিন্ন দর্শনে। Maven-এ build একটি স্থির XML বর্ণনা আর একটি নির্দিষ্ট lifecycle; Gradle-এ build একটি প্রোগ্রাম। build ফাইল লেখা হয় Kotlin বা Groovy ভাষার ছোট একটি রূপে, যাকে বলে DSL. Gradle 8.2 থেকে নতুন প্রজেক্টে ডিফল্ট হলো Kotlin DSL, ফাইলের নাম build.gradle.kts (পুরোনো Groovy রূপ build.gradle). একই “হিসাব খাতা”:

plugins {
    application                               // java plugin + "gradle run" সুবিধা
}

group = "com.abcltech"
version = "1.0.0-SNAPSHOT"

repositories {
    mavenCentral()                            // একই Maven Central
}

dependencies {
    implementation("com.fasterxml.jackson.core:jackson-databind:2.17.2")
    testImplementation(platform("org.junit:junit-bom:5.10.3"))
    testImplementation("org.junit.jupiter:junit-jupiter")
    testRuntimeOnly("org.junit.platform:junit-platform-launcher")
}

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

application {
    mainClass = "com.abcltech.hisab.Main"
}

tasks.test {
    useJUnitPlatform()                        // JUnit 5 দিয়ে টেস্ট চালানো
}

pom-এর চেয়ে ছোট, আর অনেক কিছু চেনা: একই ফোল্ডার-কাঠামো, একই GAV (এক লাইনে কোলন দিয়ে), একই Maven Central, আর platform(...) হলো BOM. সংস্করণ নম্বরগুলো এখানেও উদাহরণ। toolchain বলে এই প্রজেক্ট Java 21 দিয়ে বানাতে হবে — মেশিনে অন্য JDK চালু থাকলেও Gradle সঠিকটা খুঁজে নেয় (পর্ব ০৩-এ উল্লেখ করা সুবিধা)। আর তৈরি জিনিস যায় target/-এর বদলে build/ ফোল্ডারে।

task আর task graph

Gradle-এ Maven-এর মতো phase-এর স্থির তালিকা নেই; আছে task — compileJava, processResources, jar, test — আর তাদের মধ্যে “কে কার ওপর নির্ভর করে”-এর সম্পর্ক। ./gradlew build চালালে Gradle প্রথমে এই সম্পর্ক থেকে একটি DAG (চক্রহীন দিকনির্দেশিত গ্রাফ) বানায়, তারপর সঠিক ক্রমে task চালায়। আসল জাদু তার পরে: প্রতিটি task-এর ইনপুট আর আউটপুট মনে রাখা হয়, আর ইনপুট না বদলালে task চলেই না। একে বলে incremental build:

jar             ← compileJava, processResources
compileTestJava ← compileJava
test            ← compileJava, processResources, compileTestJava
compileJava আর processResources একে অপরের ওপর নির্ভর করে না —
তাই আলাদা থ্রেডে একসাথেও চলতে পারে

> Task :compileJava
> Task :processResources
> Task :jar
> Task :compileTestJava
> Task :test
প্রতিটি task শেষে তার ইনপুট আর আউটপুটের fingerprint সংরক্ষণ

> Task :compileJava UP-TO-DATE
> Task :processResources UP-TO-DATE
> Task :jar UP-TO-DATE
> Task :compileTestJava UP-TO-DATE
> Task :test UP-TO-DATE

> Task :compileJava UP-TO-DATE
> Task :processResources          ← ইনপুট বদলেছে
> Task :jar                       ← নতুন resource ঢোকাতে হবে
> Task :compileTestJava UP-TO-DATE
> Task :test                      ← classpath বদলেছে

$ ./gradlew clean build --build-cache
> Task :compileJava FROM-CACHE
> Task :processResources FROM-CACHE
একই ইনপুট আগে কোথাও (নিজের মেশিনে বা দলের শেয়ার করা cache-এ)
তৈরি হয়ে থাকলে আউটপুট সেখান থেকে এনে বসানো হয়

এই কৌশলের মূলটা খুব সরল — আগের ইনপুট মনে রাখা, মিলে গেলে কাজ বাদ দেওয়া। নিচের প্রোগ্রামে তিনবার build চালানো হয়েছে: প্রথমবার, কিছু না বদলে, আর শুধু একটি resource ফাইল বদলে। graph-এর ক্রম বের করা হয়েছে recursion দিয়ে — প্রতিটি task আগে তার নির্ভরতাগুলো চালায় (এটাই topological sort).

import java.util.*;

class Main {
    static final Map<String, List<String>> DEPENDS = Map.of(
        "compileJava", List.of(), "processResources", List.of(),
        "jar", List.of("compileJava", "processResources"),
        "compileTestJava", List.of("compileJava"),
        "test", List.of("compileJava", "processResources", "compileTestJava"));
    static final Map<String, String> INPUT = new HashMap<>(Map.of("compileJava", "Expense.java v1",
        "processResources", "app.properties v1", "compileTestJava", "ExpenseTest.java v1"));
    static final Map<String, String> lastRun = new HashMap<>();     // আগের build-এর fingerprint
    static int executed, upToDate;

    static String run(String task, Map<String, String> done) {
        if (done.containsKey(task)) return done.get(task);            // এই build-এ আগেই চলেছে
        StringBuilder fp = new StringBuilder(INPUT.getOrDefault(task, ""));
        for (String d : DEPENDS.get(task)) fp.append(" + ").append(run(d, done));
        String now = fp.toString();
        boolean same = now.equals(lastRun.put(task, now));
        System.out.println("> Task :" + task + (same ? " UP-TO-DATE" : ""));
        if (same) upToDate++; else executed++;
        done.put(task, now);
        return now;
    }
    public static void main(String[] args) {
        String[] titles = {"build 1: first time", "build 2: nothing changed", "build 3: only app.properties changed"};
        for (int b = 0; b < titles.length; b++) {
            if (b == 2) INPUT.put("processResources", "app.properties v2");
            executed = upToDate = 0;
            System.out.println("== " + titles[b]);
            Map<String, String> done = new HashMap<>();
            run("jar", done); run("test", done);
            System.out.println(executed + " executed, " + upToDate + " up-to-date");
        }
    }
}

implementation, api আর অন্য configuration

Maven-এর scope-এর জায়গায় Gradle-এ আছে configuration. সবচেয়ে গুরুত্বপূর্ণ পার্থক্য implementation আর api-এর মধ্যে, আর এটা বোঝা যায় যখন আপনি নিজে একটি library লেখেন:

ধরুন আপনার report-lib-এর একটি public method JsonNode toJson() ফেরত দেয় — JsonNode Jackson-এর টাইপ। তাহলে যে আপনার library ব্যবহার করবে, তার compile-এর সময়ও Jackson লাগবে: api. কিন্তু Jackson যদি শুধু ভেতরে ব্যবহার হয়, তাহলে implementation — আপনার ব্যবহারকারীর compile classpath ছোট থাকে, আর আপনি পরে Jackson বদলে Gson নিলেও তাদের কোড recompile করতে হয় না। এটা পর্ব ১৭-এর encapsulation-ই, এবার build-এর স্তরে।

৭ · Maven বনাম Gradle, আর wrapper দিয়ে একই build সবখানে

কোনটা শিখবেন? দুটোই চিনে রাখুন — কাজের প্রজেক্টে build tool সাধারণত আগেই ঠিক করা থাকে। শুরু করার জন্য Maven সহজ, আর তার ধারণাগুলো (GAV, scope, repository, transitive dependency) Gradle-এও হুবহু কাজে লাগে।

wrapper — build tool-এর version-ও পিন করা

একটি সমস্যা এখনো বাকি: আপনার মেশিনে Maven 3.9, সহকর্মীর মেশিনে Maven 3.6, CI সার্ভারে আরেকটি। একই pom, তবু আচরণ আলাদা হতে পারে। সমাধান wrapper: প্রজেক্টের ভেতরেই একটি ছোট স্ক্রিপ্ট, যা নির্দিষ্ট version-এর build tool নিজে নামিয়ে চালায়।

# Maven Wrapper একবার তৈরি করুন (মেশিনে Maven থাকতে হবে)
mvn wrapper:wrapper
# তৈরি হয়: mvnw, mvnw.cmd, .mvn/wrapper/maven-wrapper.properties

# এরপর সবাই, সবখানে — মেশিনে Maven ইনস্টল না থাকলেও
./mvnw package          # Linux/macOS
mvnw.cmd package        # Windows

# Gradle-এর ক্ষেত্রে একই ধারণা
./gradlew build         # gradle/wrapper/gradle-wrapper.properties-এ version লেখা

এই ফাইলগুলো git-এ রাখা হয়। নতুন কেউ প্রজেক্ট clone করে শুধু JDK থাকলেই ./mvnw package চালাতে পারেন — সঠিক Maven নিজে নেমে আসবে। Spring Initializr-এর তৈরি প্রজেক্টে (আর IntelliJ-এর নতুন Gradle প্রজেক্টে) wrapper আগে থেকেই থাকে। Gradle-এর properties ফাইলে distributionSha256Sum দিলে নামানো Gradle-এর checksum-ও যাচাই হয়। মনে রাখুন: নির্ভরযোগ্য build মানে তিনটি জিনিস পিন করা — JDK-র version (toolchain বা release), build tool-এর version (wrapper), আর প্রতিটি dependency ও plugin-এর version.

৮ · চালানো যায় এমন JAR, multi-module প্রজেক্ট আর JPMS

অংশ ৪-এর mvn package একটি JAR দিয়েছে। চালিয়ে দেখা যাক:

$ java -jar target/hisab-khata-1.0.0-SNAPSHOT.jar
no main manifest attribute, in target/hisab-khata-1.0.0-SNAPSHOT.jar

প্রতিটি JAR-এর ভেতরে META-INF/MANIFEST.MF নামের একটি ছোট লেখার ফাইল থাকে — manifest. java -jar সেখানে Main-Class খোঁজে: কোন class-এর main চালাতে হবে। Maven-এর সাধারণ JAR-এ এটা থাকে না, কারণ বেশিরভাগ JAR library, প্রোগ্রাম নয়। পর্ব ২২-এ jar --main-class Main দিয়ে হাতে এটা যোগ করেছিলেন। Maven-এ jar plugin-কে বলতে হয়:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jar-plugin</artifactId>
    <version>3.4.2</version>
    <configuration>
        <archive>
            <manifest>
                <mainClass>com.abcltech.hisab.Main</mainClass>
            </manifest>
        </archive>
    </configuration>
</plugin>

এবার Main চালু হয় — কিন্তু খরচ সেভ করতে গিয়ে প্রথম Jackson class-এ পৌঁছালেই NoClassDefFoundError, কারণ JAR-এ Jackson নেই। দুটি পথ: dependency-র JAR-গুলো পাশের একটি lib/ ফোল্ডারে রেখে manifest-এ Class-Path লেখা, অথবা সব কিছু একটি JAR-এ ভরে ফেলা — fat JAR (uber JAR). দ্বিতীয়টি এক ফাইলে বিতরণের জন্য খুব জনপ্রিয়:

com/abcltech/hisab/Main.class
com/abcltech/hisab/Expense.class
com/abcltech/hisab/ExpenseBook.class
app.properties

jackson-databind-2.17.2.jar
jackson-core-2.17.2.jar
jackson-annotations-2.17.2.jar
junit-jupiter বাদ — test scope চূড়ান্ত প্রোগ্রামে যায় না

com/abcltech/hisab/*.class
com/fasterxml/jackson/databind/**.class
com/fasterxml/jackson/core/**.class
META-INF/MANIFEST.MF
একই নামের ফাইল দুই JAR-এ থাকলে (যেমন META-INF/services)
transformer দিয়ে জোড়া দিতে হয়, নাহলে একটি হারায়

Manifest-Version: 1.0
Main-Class: com.abcltech.hisab.Main

$ java -jar hisab-khata-1.0.0.jar
classpath = শুধু এই একটি JAR — সব কিছু ভেতরেই

multi-module প্রজেক্ট

“হিসাব খাতা” আরও বড় হলে একে ভাগ করা যায়: hisab-core (Expense, ExpenseBook — হিসাবের নিয়ম), hisab-cli (terminal-এর মেনু), আর পরে hisab-web (Spring Boot API, পর্ব ৫১)। এটা একটি multi-module project. Maven-এ একটি অভিভাবক pom থাকে <packaging>pom</packaging> আর <modules>-এর তালিকা নিয়ে; সেখানে dependencyManagement আর plugin-এর version একবার লিখলেই সব module পায়। Gradle-এ settings.gradle.kts-এ include("hisab-core", "hisab-cli"). module-গুলো একে অপরের ওপর সাধারণ dependency-র মতোই নির্ভর করে, আর build tool সঠিক ক্রমে বানায় — core আগে, cli পরে। সবচেয়ে বড় লাভ নকশায়: hisab-core terminal বা ওয়েবের কিছুই জানে না, তাই একই হিসাবের নিয়ম CLI আর ওয়েব দুই জায়গায় ব্যবহার হয়।

JPMS module আর build tool — কে কী করে

“module” শব্দটি এখানে দুই অর্থে আসে। Maven/Gradle-এর module হলো build-এর একক — আলাদা ফোল্ডার, আলাদা JAR. Java 9-এর JPMS module হলো ভাষার একক: module-info.java-তে লেখা থাকে এটি কোন module-এর ওপর নির্ভর করে (requires com.fasterxml.jackson.databind;) আর কোন package বাইরে খোলা (exports com.abcltech.hisab.core;). দুটি পরিপূরক: build tool ঠিক করে কোন JAR-এর কোন version নামবে, JPMS ঠিক করে সেগুলোর মধ্যে কে কাকে দেখতে পাবে — requires-এ version লেখাই যায় না। module-info.java থাকলে Maven আর Gradle নিজেরাই dependency-গুলো module path-এ দেয়; তবে বেশিরভাগ অ্যাপ্লিকেশন এখনো JPMS ছাড়াই classpath-এ চলে।

৯ · CI আর supply chain — অন্যের কোডে আস্থা রাখার নিয়ম

build একটি কমান্ডে নেমে এলে সেই কমান্ড প্রতিটি কোড-পরিবর্তনে একটি সার্ভার নিজে থেকে চালাতে পারে — একে বলে CI (continuous integration). GitHub Actions-এ নিচের ফাইলটি রাখলে প্রতিটি push আর pull request-এ GitHub একটি নতুন Linux মেশিনে JDK 21 বসিয়ে ./mvnw verify চালায়; টেস্ট ভাঙলে লাল চিহ্ন:

name: build
on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: '21'
          cache: maven            # ~/.m2 সংরক্ষণ — পরের বার দ্রুত
      - run: ./mvnw -B verify     # -B: batch mode, লগ পরিষ্কার

CI মেশিনে Maven ইনস্টলের কোনো ধাপ নেই — wrapper ঠিক আপনার version-ই চালায়। আর প্রতিবার একদম নতুন মেশিন হওয়ায় লুকানো ফাইল বা হাতে বসানো JAR-এর ওপর নির্ভরতা CI-তেই ধরা পড়ে।

supply chain — আপনার প্রোগ্রামের বেশিরভাগ কোড অন্যের লেখা

mvn dependency:tree চালালে একটি অস্বস্তিকর সত্য চোখে পড়ে: একটি সাধারণ Spring Boot অ্যাপে আপনার লেখা কোডের চেয়ে transitive dependency-র কোড অনেক বেশি। এদের যেকোনো একটিতে নিরাপত্তা-ছিদ্র থাকলে সেটা আপনার অ্যাপেরও ছিদ্র। যে পথে বাইরের কোড আপনার প্রোগ্রামে ঢোকে — library-র লেখক, ভান্ডার, build tool, CI — পুরোটাই আপনার software supply chain.

পেশাদার Java দলের কয়েকটি সাধারণ অভ্যাস:

• version পিন করুন। সবসময় নির্দিষ্ট version লিখুন; LATEST, [1.0,)-এর মতো range বা Gradle-এর + এড়িয়ে চলুন — নাহলে আজকের build আর কালকের build আলাদা library পেতে পারে।
• checksum যাচাই করুন। প্রতিটি নামানো JAR-এর সাথে একটি checksum থাকে। Maven ডিফল্টে অমিল হলে সতর্ক করে, -C (strict checksums) দিলে build ব্যর্থ করে। Gradle-এর dependency verification একটি verification-metadata.xml-এ প্রতিটি JAR-এর SHA-256 লিখে রাখে আর প্রতিবার মেলায়।
• স্ক্যানার চালান। OWASP Dependency-Check (Maven ও Gradle plugin) আপনার সব dependency প্রকাশিত দুর্বলতার তালিকার সাথে মেলায়। GitHub-এর Dependabot pom বা build ফাইল পড়ে দুর্বল বা পুরোনো version-এর জন্য নিজে থেকে আপগ্রেডের pull request খোলে। mvn versions:display-dependency-updates দেখায় কোনগুলোর নতুন version এসেছে।
• কম dependency, বেশি নিরাপত্তা। প্রতিটি নতুন library-র আগে প্রশ্ন করুন: JDK নিজে কি এটা পারে (HttpClient, java.time)? library-টি কি সক্রিয়ভাবে রক্ষণাবেক্ষণ হয়?
• তালিকা রাখুন। SBOM (Software Bill of Materials) হলো আপনার প্রোগ্রামে থাকা সব component-এর যন্ত্রপাঠযোগ্য তালিকা। CycloneDX-এর মতো plugin build-এর সময় এটা বানায় — পরের Log4Shell-এ “আমরা কি এটা ব্যবহার করি?” প্রশ্নের উত্তর তখন এক মিনিটের।

১০ · AI-এর যুগে — বানানো dependency আর মিশে যাওয়া syntax

build ফাইল লেখা AI-কে দেওয়ার মতো একঘেয়ে কাজ, আর AI বেশিরভাগ সময় ভালোই লেখে। কিন্তু এখানে ভুলের বিপদ বিশেষ: ভুল library ঢুকে পড়া মানে অন্যের কোড আপনার সার্ভারে চলা।

সবচেয়ে গুরুতর সমস্যা হলো বানানো dependency. AI মাঝে মাঝে এমন groupId, artifactId বা version লেখে, যা দেখতে একদম বিশ্বাসযোগ্য কিন্তু বাস্তবে নেই — যেমন একটি সত্যিকারের library-র নামের সাথে -utils বা -starter জুড়ে দেওয়া, অথবা এমন version নম্বর, যা কখনো প্রকাশই হয়নি। কয়েকটি গবেষণায় দেখা গেছে, AI-এর সুপারিশ করা package-এর একটি উল্লেখযোগ্য অংশ বাস্তবে নেই, আর একই বানানো নাম বারবার আসে। আক্রমণকারীরা এই সুযোগ নিতে পারে: সেই বানানো নামে আগেভাগে একটি ক্ষতিকর package প্রকাশ করে রাখা, যাতে কেউ AI-এর কথামতো যোগ করলেই তাদের কোড ঢুকে পড়ে। এর নাম দেওয়া হয়েছে slopsquatting. Maven Central-এ নতুন groupId প্রকাশ করতে ডোমেইন বা কোড-হোস্টিং অ্যাকাউন্টের মালিকানা প্রমাণ করতে হয়, তাই npm বা PyPI-এর চেয়ে কাজটা কঠিন — কিন্তু অসম্ভব নয়, আর Gradle plugin বা অন্য repository-র ক্ষেত্রে নিয়ম আলাদা হতে পারে।

AI-এর লেখা build ফাইল হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি groupId:artifactId Maven Central-এ খুঁজে পেয়েছি, আর সেটা library-র অফিসিয়াল ডকুমেন্টেশনে লেখা নামের সাথে মেলে
• প্রতিটি version সত্যিই প্রকাশিত, stable (alpha/RC নয়), আর খুব পুরোনো নয়
• ফাইলে শুধু একটি টুলের syntax — pom.xml-এ XML, build.gradle.kts-এ Kotlin DSL
• টেস্ট library test scope বা testImplementation-এ; JDK যা পারে তার জন্য বাড়তি library নেই
• Java 21 নির্দিষ্ট করা (release বা toolchain); plugin-এর version লেখা; কোনো range বা + নেই
• mvn dependency:tree বা ./gradlew dependencies চালিয়ে transitive গাছ দেখেছি — অচেনা কিছু নেই, সংঘাত নেই
• wrapper ব্যবহার করে পরিষ্কার মেশিনে (বা CI-তে) build সফল হয়েছে