1. Learning Outcomes#

2. एक सामान्य Team Problem से शुरुआत करें#

मान लीजिए एक Java project पर तीन developers काम कर रहे हैं।

पहले developer के laptop पर Maven 3.9.x है।

दूसरे developer के laptop पर Maven का कोई दूसरा version है।

CI server पर Maven version फिर अलग है।

सभी लोग repository से वही source code checkout करते हैं, फिर भी build environment पूरी तरह समान नहीं है।

कोई developer command चलाता है:

mvn clean verify

यह command project से Maven नहीं लेती।

यह operating system के PATH में उपलब्ध Maven installation को use करती है।

इसका मतलब है कि build का एक महत्वपूर्ण हिस्सा project के बाहर control हो रहा है।

यहीं Maven Wrapper उपयोगी होता है।

3. Maven Wrapper क्या है?#

Maven Wrapper को सरल mental model से समझें।

Normally आप Maven चलाते हैं:

mvn clean verify

यहाँ mvn आपके computer पर पहले से installed Maven को represent करता है।

Wrapper use करने पर Unix-like system में command होती है:

./mvnw clean verify

Windows पर वही idea mvnw.cmd के माध्यम से use होती है।

Wrapper script project की configuration देखती है और यह पता करती है कि project किस Maven distribution को use करना चाहता है।

जरूरत होने पर वह configured Maven distribution download करती है।

उसके बाद उसी Maven installation से requested build run होता है।

इस flow को देखें:

Flow की शुरुआत developer या CI runner से होती है।

वह सीधे machine के mvn command पर निर्भर रहने के बजाय Wrapper script चलाता है।

Wrapper configuration से Maven distribution पता चलता है।

फिर उसी Maven distribution के साथ build execute होता है।

4. Maven Version Pin करने की जरूरत क्यों पड़ती है?#

Software project में केवल source code consistent होना पर्याप्त नहीं होता।

Build tool का version भी behavior को प्रभावित कर सकता है।

अलग Maven versions के बीच:

• bug fixes बदल सकते हैं,
• plugin handling में differences आ सकते हैं,
• warnings बदल सकती हैं,
• supported behavior evolve हो सकता है,
• Java compatibility requirements बदल सकती हैं।

इसलिए team अक्सर एक approved Maven version तय करती है।

मान लीजिए project के लिए Maven 3.9.11 approve किया गया है।

अगर सभी developers केवल अपने global mvn command पर depend करते हैं, तो हर machine पर यही version होने की guarantee नहीं है।

Wrapper इस dependency को project-controlled configuration में बदल देता है।

इसका practical goal है:

same repository + same Wrapper configuration → same Maven version

यह complete reproducibility की अकेली guarantee नहीं है, क्योंकि JDK, operating system, environment variables और dependencies जैसी दूसरी चीजें भी build को प्रभावित कर सकती हैं।

लेकिन Maven version drift को हटाने के लिए Wrapper बहुत महत्वपूर्ण step है।

5. System-Installed Maven और Maven Wrapper में अंतर#

सबसे महत्वपूर्ण difference command के spelling में नहीं है।

असल difference यह है कि Maven selection का control कहाँ रखा गया है।

mvn में control machine के environment के पास होता है।

./mvnw या mvnw.cmd में Maven distribution selection project Wrapper configuration से आता है।

6. Maven Wrapper की मुख्य Files#

Wrapper generate करने के बाद project में सामान्यतः ये महत्वपूर्ण parts होते हैं।

Wrapper generation mode और Maven Wrapper version के अनुसार .mvn/wrapper के अंदर additional implementation files भी हो सकती हैं।

इसलिए किसी project में केवल एक particular file set देखकर यह assume नहीं करना चाहिए कि हर Wrapper generation हमेशा बिल्कुल वैसी ही होगी।

लेकिन fresher के लिए तीन concepts सबसे महत्वपूर्ण हैं:

1. command entry point
2. Wrapper configuration
3. Maven distribution bootstrap

7. .mvn/wrapper Directory का Role#

.mvn project-level Maven configuration directory है।

उसके अंदर wrapper directory Wrapper-specific configuration रखती है।

मुख्य path है:

.mvn/wrapper/maven-wrapper.properties

इसे केवल एक random configuration file न समझें।

यह Wrapper को बताती है कि Maven distribution कहाँ से प्राप्त करनी है।

इस कारण Wrapper scripts और Wrapper properties एक-दूसरे से जुड़े हुए हैं।

Script execution शुरू करती है।

Properties configuration देती है।

Configured Maven distribution actual Maven build चलाती है।

8. maven-wrapper.properties को समझें#

इस file में सबसे महत्वपूर्ण configuration में से एक distributionUrl है।

उदाहरण के लिए team ने Maven 3.9.11 approve किया हो, तो distribution URL उस version की Maven binary distribution की ओर point कर सकता है।

उदाहरण value:

https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.9.11/apache-maven-3.9.11-bin.zip

यहाँ path को ध्यान से पढ़ें।

उसमें Maven version 3.9.11 दिखाई दे रहा है।

यही idea Maven version pinning के पीछे है।

Project configuration किसी known Maven distribution को refer करती है।

कुछ Wrapper configurations में अन्य properties भी हो सकती हैं।

लेकिन इस chapter में सबसे महत्वपूर्ण learner takeaway distributionUrl और Maven distribution selection है।

9. Existing Project में Maven Wrapper Generate करना#

Wrapper create करने के लिए existing Maven installation से Wrapper goal run किया जा सकता है।

Project root directory में:

mvn wrapper:wrapper

यहाँ एक महत्वपूर्ण point है।

Wrapper generate करने की initial bootstrap step में आपको Maven उपलब्ध होना चाहिए।

लेकिन Wrapper files repository में commit हो जाने के बाद बाकी developers को normal builds के लिए अपने global Maven installation पर depend करने की जरूरत नहीं रहती।

अगर team किसी specific Maven version के लिए Wrapper configure करना चाहती है, तो approved version specify किया जा सकता है।

उदाहरण:

mvn wrapper:wrapper -Dmaven=3.9.11

यहाँ 3.9.11 केवल एक concrete example है।

Real project में वही Maven version use करें जिसे team ने test और approve किया है।

Wrapper generate होने के बाद configuration review करना अच्छी practice है।

विशेष रूप से verify करें:

• mvnw मौजूद है,
• mvnw.cmd मौजूद है,
• .mvn/wrapper configuration मौजूद है,
• desired Maven distribution configured है।

10. Unix-Like Systems पर Wrapper से Build चलाना#

Linux और macOS जैसे Unix-like environments में project root से सामान्य command है:

./mvnw clean verify

यहाँ ./ महत्वपूर्ण है।

इसका अर्थ है current project directory में मौजूद mvnw script execute करना।

Compare करें:

mvn clean verify → system Maven

./mvnw clean verify → project Maven Wrapper

यही छोटा-सा command difference reproducible team workflow में बड़ा impact डाल सकता है।

अगर Permission Denied मिले#

Unix-like systems में script executable होनी चाहिए।

यदि executable permission missing है, तो इसे set किया जा सकता है:

chmod +x mvnw

यदि executable permission repository workflow का हिस्सा है, तो उसका file-mode change भी version control में preserve होना चाहिए।

11. Windows पर Wrapper से Build चलाना#

Windows project में Wrapper entry point है:

mvnw.cmd

Command Prompt में सामान्य command:

mvnw.cmd clean verify

PowerShell में current directory से explicit invocation इस प्रकार किया जा सकता है:

.\mvnw.cmd clean verify

यह वही Maven lifecycle goals run करता है जिन्हें आप सामान्य Maven command में use करते।

Difference lifecycle में नहीं है।

Difference Maven executable selection के रास्ते में है।

12. First Run पर Automatic Maven Download कैसे होता है?#

Wrapper का एक major benefit यह है कि configured Maven distribution machine पर पहले से installed होना जरूरी नहीं है।

पहली बार Wrapper चलाने पर flow सामान्यतः ऐसा होता है:

इसे step-by-step समझें।

Step 1: Wrapper script शुरू होती है#

Developer ./mvnw या mvnw.cmd चलाता है।

Step 2: Wrapper configuration read होती है#

Wrapper configured Maven distribution की information प्राप्त करता है।

Step 3: Local cache check होता है#

अगर required Maven distribution पहले से available है, तो दोबारा पूरा distribution download करने की जरूरत नहीं होती।

Step 4: जरूरत होने पर Maven download होता है#

अगर distribution local cache में नहीं है, तो Wrapper configured location से उसे download करता है।

Step 5: Requested Maven goals execute होते हैं#

उसके बाद Maven clean, test, package, verify जैसी requested lifecycle phases/goals execute करता है।

इसलिए first Wrapper execution बाद की executions से थोड़ा अलग अनुभव दे सकती है।

पहली बार network download की जरूरत हो सकती है।

बाद में cached distribution reuse हो सकती है।

13. Distribution Version और URL Configure करना#

Version pinning को practical तरीके से समझें।

मान लीजिए project आज Maven 3.9.11 पर validated है।

Team को सिर्फ documentation में यह लिखने के बजाय Wrapper configuration में वही Maven distribution define करनी चाहिए।

इससे new developer को अलग से यह याद रखने की जरूरत नहीं रहती कि कौन-सा Maven version install करना है।

Team बाद में Maven version upgrade करना चाहे, तो controlled process use कर सकती है:

1. नया Maven version select करें।
2. Wrapper configuration update करें।
3. project build और tests चलाएँ।
4. CI verification करें।
5. Wrapper change commit करें।

इससे Maven upgrade भी source-controlled change की तरह review हो सकता है।

14. Wrapper Files को Version Control में क्यों Commit करना चाहिए?#

Wrapper का पूरा फायदा तभी मिलता है जब repository checkout करने वाले व्यक्ति के पास Wrapper files भी पहुँचें।

इसलिए Wrapper files सामान्यतः Git repository में commit की जाती हैं।

उदाहरण:

git add mvnw mvnw.cmd .mvn/wrapper
git commit -m "Add Maven Wrapper"

इसके बाद नया developer repository clone करके project-provided build command use कर सकता है।

अगर Wrapper files commit नहीं की गईं, तो हर developer को Wrapper manually generate करना पड़ सकता है।

इससे consistency का purpose कमजोर हो जाता है।

Repository में Maven Distribution ZIP Commit करनी चाहिए?#

नहीं।

Wrapper mechanism का purpose Maven binary distribution को source repository में manually copy करना नहीं है।

Repository में Wrapper bootstrap/configuration रहती है।

Configured Maven distribution जरूरत के अनुसार obtain की जाती है।

इस distinction को याद रखें:

Wrapper configuration commit करें; downloaded Maven installation को source code की तरह commit न करें।

15. Local Development में Wrapper को Standard बनाना#

Team के लिए सबसे useful rule यह है कि Maven commands का standard entry point Wrapper हो।

उदाहरण:

./mvnw clean
./mvnw test
./mvnw package
./mvnw verify

Developer को global Maven install होने से कोई problem नहीं है।

लेकिन project build के लिए team यदि Wrapper standardize करती है, तो accidental version differences कम होते हैं।

इसका मतलब system Maven useless नहीं है।

System Maven Wrapper generate करने, experiments करने या दूसरे projects के लिए useful हो सकता है।

लेकिन किसी specific Wrapper-enabled project में consistent workflow के लिए Wrapper preferred entry point होता है।

16. CI में Maven Wrapper Use करना#

Consistency केवल developer laptops तक सीमित नहीं होनी चाहिए।

CI भी उसी project build process का हिस्सा है।

अगर developer locally यह चलाता है:

./mvnw clean verify

लेकिन CI यह चलाता है:

mvn clean verify

तो दोनों environments Maven selection के लिए अलग strategy use कर रहे हैं।

Local build project Wrapper पर depend कर रहा है।

CI build CI image में preinstalled Maven पर depend कर रहा है।

Better model है:

यहाँ developer और CI दोनों repository में मौजूद Wrapper use करते हैं।

इससे Maven version selection का एक common source बनता है।

CI में सामान्य build commands उदाहरण के लिए:

./mvnw --version
./mvnw clean verify

पहली command troubleshooting के लिए useful है क्योंकि logs में actual Maven और Java environment दिखाई दे सकता है।

दूसरी command actual validation build चलाती है।

17. Maven Wrapper और JDK एक ही चीज नहीं हैं#

यह chapter का बहुत महत्वपूर्ण concept है।

Maven Java application है।

Maven को run होने के लिए Java runtime चाहिए।

Wrapper Maven version select कर सकता है।

लेकिन इसका अर्थ यह नहीं है कि Wrapper automatically project का JDK version भी pin कर देता है।

मान लीजिए:

• Developer A Wrapper से Maven 3.9.11 चला रहा है।
• Developer B भी Wrapper से Maven 3.9.11 चला रहा है।

फिर भी Developer A Java 17 use कर सकता है और Developer B Java 21।

इसलिए Maven consistency और JDK consistency दो अलग concerns हैं।

इस relationship को देखें:

JDK Maven process को run करने के लिए Java environment देता है।

Wrapper यह तय करने में मदद करता है कि Maven का कौन-सा distribution use होगा।

दोनों मिलकर build environment को प्रभावित करते हैं, लेकिन दोनों एक-दूसरे के replacement नहीं हैं।

18. JDK Difference को कैसे पहचानें?#

Troubleshooting के समय केवल Maven version देखना पर्याप्त नहीं होता।

Java environment भी check करें।

उदाहरण:

java -version
./mvnw --version

java -version selected Java installation के बारे में information देता है।

Wrapper का Maven version command Maven execution environment को verify करने में मदद करता है।

अगर Wrapper के बावजूद किसी एक machine पर build fail हो रहा है, तो अगली checks में JDK version और environment configuration शामिल होनी चाहिए।

19. Environment-Specific Maven Differences कैसे Avoid करें?#

एक practical team policy इस प्रकार हो सकती है।

1. Approved Maven version तय करें#

Randomly latest version use करने के बजाय tested version choose करें।

2. Maven Wrapper generate करें#

Wrapper project repository का हिस्सा बनाएँ।

3. Configuration review करें#

Configured Maven distribution verify करें।

4. Wrapper files Git में commit करें#

इससे हर checkout को same bootstrap configuration मिलेगी।

5. Developers Wrapper commands use करें#

Unix-like environment में ./mvnw और Windows में mvnw.cmd use करें।

6. CI भी Wrapper use करे#

Local और CI Maven entry point अलग न रखें।

7. JDK को separately control करें#

CI में required JDK explicitly configure करें और team development requirements document करें।

यह combined approach Maven-version drift का बड़ा source remove कर देता है।

20. System Maven होने पर भी Wrapper क्यों Use करें?#

यह beginner confusion common है।

Laptop पर Maven पहले से installed हो सकता है।

फिर भी Wrapper useful है।

कारण यह है कि सवाल केवल यह नहीं है कि Maven available है या नहीं।

सवाल यह है कि कौन-सा Maven version build चला रहा है।

Global installation personal machine configuration है।

Wrapper project configuration है।

Team project में project-controlled choice अधिक predictable होती है।

21. Wrapper हर Build Difference Solve नहीं करता#

Wrapper बहुत useful है, लेकिन इसे magic reproducibility button नहीं समझना चाहिए।

यह मुख्य रूप से Maven bootstrap और Maven distribution consistency solve करता है।

Build differences अभी भी दूसरी चीजों से आ सकती हैं, जैसे:

• अलग JDK versions,
• environment variables,
• operating-system differences,
• network/repository availability,
• external services,
• machine-specific configuration।

इसलिए सही statement यह है:

Maven Wrapper Maven-version consistency का एक महत्वपूर्ण foundation है।

यह हर possible environment difference का अकेला solution नहीं है।

22. Common Mistakes#

System Maven और Wrapper को बिना सोचे mix करना#

एक developer mvn use करता है और दूसरा ./mvnw।

इससे दोनों अलग Maven versions चला सकते हैं।

Team convention clear रखें।

Wrapper generate करके Git में commit न करना#

ऐसा करने पर दूसरे developers को Wrapper नहीं मिलेगा।

Consistency repository के साथ travel नहीं करेगी।

केवल mvnw देखकर Maven version assume करना#

Actual version intent Wrapper configuration से समझें।

Wrapper को JDK manager समझना#

Wrapper Maven distribution standardize करता है।

JDK अलग environment concern है।

CI में system Maven use करना#

Local Wrapper और CI system Maven use करने से environment drift वापस आ सकती है।

First download requirement भूल जाना#

Fresh machine पर configured Maven distribution download करना पड़ सकता है।

Restricted network environment में यह पहले से consider करना चाहिए।

23. एक Practical Team Workflow#

मान लीजिए team ने नया Java project Wrapper-enabled बनाया है।

Developer repository clone करता है।

Unix-like system पर वह चलाता है:

./mvnw clean verify

Windows developer equivalent Wrapper command use करता है।

CI भी checked-in Wrapper use करता है।

अगर team Maven upgrade करना चाहती है, तो Wrapper configuration controlled commit के रूप में update की जाती है।

इस तरह Maven version personal machine preference नहीं रहता।

वह project build decision बन जाता है।

24. Recap#

इस chapter से मुख्य बातें याद रखें:

• Maven Wrapper project-controlled Maven execution देता है।
• mvn आम तौर पर system-installed Maven use करता है।
• ./mvnw या mvnw.cmd project Wrapper use करता है।
• .mvn/wrapper/maven-wrapper.properties Maven distribution configuration का महत्वपूर्ण हिस्सा है।
• Wrapper जरूरत होने पर configured Maven distribution download कर सकता है।
• Wrapper files को repository में commit करना चाहिए ताकि developers और CI दोनों उन्हें use कर सकें।
• Local development और CI दोनों में Wrapper use करने से Maven-version drift कम होती है।
• Wrapper Maven version को standardize करता है; JDK selection अलग concern है।
• Reproducible build environment के लिए Maven और JDK दोनों को consciously manage करना चाहिए।