Build tools aur dependency management — Maven ya Gradle

Dependency management wo jagah hai jahan AI projects chup-chaap bigadte hain. Ye ecosystem itni tezi se chalta hai ki ek dheela-dhaala version aapki us build ko tod deta hai jise aapne chhua bhi nahi tha. Aur mismatched module versions aise errors dete hain jo dekhne mein aapke code ke bug lagte hain. Build theek kar lena ghanton ki dikkat bacha deta hai.

Sabse pehle: BOM kya hota hai#

BOM ka matlab hai Bill of Materials — ek chhoti si file jo kehti hai "is library ke in saare modules ka ye version aapas mein test kiya hua hai".

Iske bina kya hota hai, wo dekhiye. Aapne spring-ai-openai ka version 1.0.0 liya, aur do hafte baad spring-ai-pgvector add kiya aur unknowingly 1.0.2 aa gaya. Build ho jaayegi. Application start bhi ho jaayegi. Aur phir ek din production mein NoSuchMethodError milega, jiska aapke code se koi lena dena nahi hai.

Maven mein BOM aise lagta hai:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.springframework.ai</groupId>
      <artifactId>spring-ai-bom</artifactId>
      <version>${spring-ai.version}</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

Uske baad har Spring AI dependency bina version ke likhi jaati hai:

<dependency>
  <groupId>org.springframework.ai</groupId>
  <artifactId>spring-ai-starter-model-openai</artifactId>
</dependency>

Gradle mein wahi baat:

dependencies {
    implementation(platform("org.springframework.ai:spring-ai-bom:$springAiVersion"))
    implementation("org.springframework.ai:spring-ai-starter-model-openai")
}

LangChain4j ka bhi apna BOM hai aur wo bilkul isi tarah lagta hai. Rule ek hi hai: AI library ka version poore project mein sirf ek jagah likha hona chahiye.

Maven ya Gradle — seedha faisla#

Maven lijiye agar:

• Team Spring ki documentation follow karke chalti hai (wahan zyadatar Maven hi hai).
• Build ka behaviour predictable rehna zyada important hai speed se.
• Aapko XML se dikkat nahi hai — aur XML ka ek fayda hai, usme chhupa hua logic nahi ho sakta.

Gradle lijiye agar:

• Project bada hai aur incremental build ki speed sach mein farak daalti hai.
• Multi-module setup hai aur aapko version catalog chahiye.
• Build mein kuch custom logic likhna hai (Gradle isme Maven se bahut aage hai).

Gradle ka version catalog ek jagah saare versions rakhta hai, gradle/libs.versions.toml mein:

[versions]
spring-ai = "1.0.0"
langchain4j = "1.0.0"
 
[libraries]
spring-ai-bom = { module = "org.springframework.ai:spring-ai-bom", version.ref = "spring-ai" }
langchain4j-bom = { module = "dev.langchain4j:langchain4j-bom", version.ref = "langchain4j" }

Ab har module libs.spring.ai.bom likhta hai aur version sirf ek file mein badalta hai.

Multi-module — kab, aur kab nahi#

Har AI project ko modules mein todne ki zaroorat nahi hai. Lekin ek pattern aksar sach mein kaam ka nikalta hai: ingestion alag, serving alag.

myapp/
  pom.xml              <- parent, sirf versions aur module list
  myapp-core/          <- domain records, shared interfaces
  myapp-ingestion/     <- PDF/Office parsers, splitter, embedding job
  myapp-api/           <- REST controllers, chat client, retrieval

Ye batwara isliye kaam karta hai kyunki ingestion bhaari document parsers kheenchti hai (Tika, PDFBox, POI) jinki serving ko zaroorat hi nahi. Alag rakhne se aapka API container chhota rehta hai, start fast hota hai, aur uska attack surface kam hota hai.

Aur ye batwara mat kijiye jab dono hisse ek hi time par deploy hote hain aur ek hi jaisi dependencies use karte hain. Us case mein aapne sirf paanch nayi files add ki hain aur kuch nahi.

Dependency hygiene — teen aadat#

1. Version kabhi khula mat chhodiye. LATEST, +, ya 1.0.+ — inka matlab hai ki aapki build kal apne aap badal sakti hai. Reproducible build ke bina debugging andhere mein teer chalana hai.

2. Kya-kya aa raha hai, ye dekhte rahiye. AI starters bahut kuch transitively kheench laate hain:

mvn dependency:tree -Dincludes=dev.langchain4j
./gradlew dependencies --configuration runtimeClasspath

Ek hi library do versions mein dikh rahi ho to wahi aapka agla mysterious bug hai.

3. Model API keys ko build se door rakhiye. Key kabhi pom.xml, build.gradle ya application.yml mein commit nahi honi chahiye. Environment variable lijiye:

spring:
  ai:
    openai:
      api-key: ${OPENAI_API_KEY}

Aage kya#

Build theek hai, versions pinned hain, aur project ka shape decide ho gaya hai. Agla sawaal ye hai ki ye application chalegi kahan — yaani Docker image aur Kubernetes deployment.