מבוא ל- Maven 2

Maven הוא כלי לבניית קוד פתוח פופולרי עבור פרויקטים של Java ארגוניים, שנועד להוציא חלק גדול מהעבודה הקשה מתהליך הבנייה. Maven משתמש בגישה הצהרתית, שבה מתארים את מבנה הפרויקט ותוכנו, ולא את הגישה מבוססת המשימות המשמשת ב- Ant או בקבצי ייצור מסורתיים, למשל. זה עוזר לאכוף תקני פיתוח כלל חברות ומפחית את הזמן הדרוש לכתיבה ותחזוקת סקריפטים לבנייה.

הגישה ההצהרתית ומבוססת על מחזור החיים בה משתמש Maven 1 היא, עבור רבים, סטייה רדיקלית מטכניקות בנייה מסורתיות יותר, ו- Maven 2 מרחיק לכת עוד יותר בהקשר זה. במאמר זה אני עובר על כמה מהעקרונות הבסיסיים שעומדים מאחורי Maven 2 ואז עובר על דוגמא לעבודה. נתחיל בסקירת היסודות של Maven 2.

מודל האובייקט של הפרויקט

ליבו של פרויקט Maven 2 הוא מודל אובייקט הפרויקט (או בקיצור POM). הוא מכיל תיאור מפורט של הפרויקט שלך, כולל מידע על גרסאות וניהול תצורה, תלות, משאבי יישומים ובדיקות, חברי צוות ומבנה ועוד. ה- POM לובש צורה של קובץ XML ( pom.xml ), שממוקם בספריית הבית של הפרויקט שלך. קובץ pom.xml פשוט מוצג כאן:

 4.0.0 com.javaworld.hotels HotelDatabase war 1.0-SNAPSHOT Maven Quick Start Archetype //maven.apache.org   junit junit 3.8.1 test   

מבנה המדריך Maven 2

הרבה מכוחו של מייבן נובע מהפרקטיקות הסטנדרטיות שהוא מעודד. מפתח שעבד בעבר על פרויקט Maven ירגיש מיד מכיר את המבנה והארגון של חדש. אין לבזבז זמן להמציא מחדש מבני ספריות, מוסכמות ותסריטי בניית נמלים מותאמים אישית לכל פרויקט. למרות שאתה יכול לעקוף כל מיקום ספרייה מסוים למטרות ספציפיות משלך, אתה באמת צריך לכבד את מבנה הספריות הסטנדרטי של Maven 2 ככל האפשר, מכמה סיבות:

  • זה הופך את קובץ ה- POM שלך לקטן ופשוט יותר
  • זה מקל על הבנת הפרויקט ומקל על החיים של המסכן שחייב לתחזק את הפרויקט כשאתה עוזב
  • זה מקל על שילוב התוספים

מבנה הספריות הסטנדרטי של Maven 2 מודגם באיור 1. בספריית הבית של הפרויקט נכנסים POM (pom.xml) ושתי ספריות משנה: src לכל קוד המקור והיעד לחפצים שנוצרו.

בספריית src יש מספר ספריות משנה, שלכל אחת מהן מטרה מוגדרת בבירור:

  • src / main / java: קוד המקור שלך ב- Java הולך לכאן (באופן מוזר!)
  • src / main / resources: משאבים אחרים שהיישום שלך זקוק להם
  • src / main / filters: מסנני משאבים, בצורה של קבצי מאפיינים, המשמשים להגדרת משתנים הידועים רק בזמן הריצה
  • src / main / config: קבצי תצורה
  • src / main / webapp: ספריית יישומי האינטרנט לפרויקט WAR
  • src / test / java: מבחני יחידות
  • src / test / resources: משאבים שישמשו לבדיקות יחידה, אך לא ייפרסו
  • src / test / filters: מסנני משאבים שישמשו לבדיקות יחידה, אך לא ייפרסו
  • src / site: קבצים המשמשים להפקת אתר Maven פרויקט

מחזורי חיים של פרויקט

מחזורי החיים של הפרויקט הם מרכזיים ב- Maven 2. מרבית המפתחים מכירים את הרעיון של שלבי בנייה כגון קומפילציה, בדיקה ופריסה. לנמלה יש מטרות עם שמות כאלה. ב- Maven 1, יישומי פלאגין מתאימים נקראים ישירות. לצורך הידור קוד המקור של Java, למשל, נעשה שימוש javaבתוסף:

$maven java:compile

ב- Maven 2, תפיסה זו מתוקננת למכלול שלבי מחזור חיים ידועים ומוגדרים היטב (ראה איור 2). במקום פניית תוספות, היזם 2 מייבן ומפעיל שלב במחזור חיים: $mvn compile.

כמה משלבי מחזור החיים Maven 2 השימושיים יותר הם הבאים:

  • generate-sources: מייצר כל קוד מקור נוסף הדרוש ליישום, שבדרך כלל מתבצע באמצעות התוספים המתאימים
  • compile: מרכיב את קוד המקור של הפרויקט
  • test-compile: מרכיב את מבחני יחידת הפרויקט
  • test: מריץ את בדיקות היחידה (בדרך כלל באמצעות JUnit) בספריית src / test
  • package: מארז את הקוד המהולל בפורמט ההפצה שלו (JAR, WAR וכו ')
  • integration-test: מעבד ומפרס את החבילה במידת הצורך בסביבה בה ניתן להריץ בדיקות אינטגרציה
  • install: מתקין את החבילה במאגר המקומי לשימוש כתלות בפרויקטים אחרים במחשב המקומי שלך
  • deploy: נעשה בסביבת אינטגרציה או שחרור, מעתיק את החבילה הסופית למאגר המרוחק לשיתוף עם מפתחים ופרויקטים אחרים

ישנם שלבים רבים אחרים של מחזור החיים. ראה משאבים לפרטים נוספים.

שלבים אלה ממחישים את היתרונות של השיטות המומלצות שעודדו Maven 2: ברגע שמפתח מכיר את שלבי מחזור החיים העיקריים של Maven 2, עליו להרגיש בנוח עם שלבי מחזור החיים של כל פרויקט Maven.

שלב מחזור החיים מפעיל את התוספים הדרושים לו כדי לבצע את העבודה. הפעלת שלב מחזור חיים קוראת אוטומטית גם לכל שלבי מחזור החיים הקודמים. מכיוון ששלבי מחזור החיים מוגבלים במספר, קלים להבנה ומאורגנים היטב, קל להכיר את מחזור החיים של פרויקט Maven 2 חדש.

תלות מעבר

אחד משיאי ה- Maven 2 הוא ניהול תלות מעבר. אם אי פעם השתמשת בכלי כמו urpmi בתיבת לינוקס, תדע מהן תלות מעבר. עם Maven 1, אתה צריך להצהיר על כל JAR ויהיה צורך ביישום שלך באופן ישיר או עקיף. לדוגמה, האם תוכל לרשום את ה- JAR הדרוש ליישום שינה? עם Maven 2, אתה לא צריך. אתה פשוט אומר למיין אילו ספריות אתה צריך, ומייבן ידאג לספריות שהספריות שלך צריכות (וכן הלאה).

נניח שאתה רוצה להשתמש ב- Hibernate בפרויקט שלך. אתה פשוט מוסיף תלות חדשה dependenciesלסעיף ב- pom.xml, כדלקמן:

  hibernate hibernate 3.0.3 compile 

וזה הכל! אתה לא צריך להסתובב כדי לדעת באילו JARs אחרים (ובאילו גרסאות) אתה צריך להפעיל את Hibernate 3.0.3; מייבן יעשה את זה בשבילך!

מבנה ה- XML ​​לתלות ב- Maven 2 דומה לזה המשמש ב- Maven 1. ההבדל העיקרי הוא scopeהתג, שמוסבר בסעיף הבא.

היקפי תלות

ביישום ארגוני בעולם האמיתי, ייתכן שלא תצטרך לכלול את כל התלות ביישום הפרוס. חלק מה- JAR נחוצים רק לבדיקת יחידות, בעוד שאחרים יסופקו בזמן הריצה על ידי שרת היישומים. באמצעות טכניקה הנקראת סקירת תלות , Maven 2 מאפשר לך להשתמש ב- JAR מסוימים רק כשאתה באמת זקוק להם ואינו מוציא אותם ממסלול הכיתה כשאינך צריך.

Maven מספק ארבעה טווחי תלות:

  • compile: תלות בהיקף הידור זמינה בכל השלבים. זהו ערך ברירת המחדל.
  • provided: תלות מסופקת משמשת לקומפילציה של היישום, אך לא תיפרס. היית משתמש בהיקף זה כאשר אתה מצפה ש- JDK או שרת היישומים יספקו את ה- JAR. ממשקי ה- API של servlet הם דוגמה טובה.
  • runtime: אין צורך בתלות בהיקף זמן ריצה לצורך הידור, אלא רק לביצוע, כגון מנהלי התקן JDBC (Java Database Connectivity).
  • test: תלות בהיקף הבדיקה נחוצה רק לצורך הידור והפעלת בדיקות (JUnit, למשל).

תקשורת פרויקט

חלק חשוב בכל פרויקט הוא תקשורת פנימית. אמנם לא מדובר בכדור כסף, אולם פרויקט טכני מרכזי יכול לעשות דרך ארוכה לשיפור הנראות בצוות. במאמץ מינימלי תוכלו להפעיל אתר פרוייקט באיכות מקצועית תוך מעט מאוד זמן.

זה מקבל מימד חדש לגמרי כאשר דור האתר של Maven משולב בתהליך בנייה באמצעות אינטגרציה מתמשכת או אפילו בנייה לילית אוטומטית. אתר Maven טיפוסי יכול לפרסם על בסיס יומי:

  • מידע כללי על הפרויקט כגון מאגרי מקורות, מעקב אחר פגמים, חברי צוות וכו '.
  • בדיקות יחידה ודוחות כיסוי מבחן
  • ביקורות קוד אוטומטיות ועם Checkstyle ו- PMD
  • מידע על תצורה וגרסאות
  • תלות
  • ג'אדוק
  • קוד מקור בפורמט HTML עם אינדקס ומוצלב
  • רשימת חברי הקבוצה
  • ועוד הרבה

שוב, כל מפתח מתמצא ב- Maven יידע מיד היכן לחפש להכיר פרויקט Maven 2 חדש.

דוגמא מעשית

כעת, כשראינו כמה מן הרעיונות הבסיסיים המשמשים ב- Maven 2, בואו נראה איך זה עובד בעולם האמיתי. שאר מדריך זה בוחן כיצד היינו משתמשים ב- Maven 2 בפרויקט פשוט של Enterprise Enterprise Edition. אפליקציית ההדגמה כוללת מערכת בסיסי דמיוני (ופשוטה) של מלונות. כדי להדגים כיצד Maven מטפל בתלות בין פרויקטים לרכיבים, יישום זה ייבנה באמצעות שני רכיבים (ראה איור 3):

  • מרכיב לוגי עסקי: HotelDatabase.jar
  • רכיב יישומי אינטרנט: HotelWebApp.war

אתה יכול להוריד את קוד המקור כדי לעקוב אחר ההדרכה במשאבים.

הגדר את סביבת הפרויקט שלך

ראשית אנו מגדירים את סביבת העבודה שלך. בפרויקטים בעולם האמיתי, לרוב יהיה עליכם להגדיר ולהגדיר תצורה של פרמטרים סביבתיים או ספציפיים למשתמשים שאינם צריכים להיות מופצים לכל המשתמשים. אם אתה עומד מאחורי חומת אש עם שרת proxy, למשל, עליך להגדיר את הגדרות ה- proxy כך ש- Maven יוכל להוריד JAR ממאגרים באינטרנט. עבור משתמשי Maven 1, הקבצים build.properties ו- project.properties מבצעים את העבודה הזו. ב- Maven 2 הם הוחלפו בקובץ settings.xml שנכנס לספריית $ HOME / .m2. הנה דוגמה:

     http scott tiger 8080 my.proxy.url    

צור פרויקט חדש באמצעות התוסף ארכיטיפ

השלב הבא הוא ליצור תבנית פרוייקט חדשה של Maven 2 עבור רכיב ההיגיון העסקי. Maven 2 מספק את archetypeהתוסף, שבונה מבנה ספריית פרויקטים תואם Maven 2 ריק. התוסף הזה מוכיח שהוא נוח להפעלת סביבת פרויקטים בסיסית במהירות. דגם הארכיטיפ המוגדר כברירת מחדל יפיק פרויקט ספריית JAR. קיימים מספר סוגי חפצים אחרים עבור סוגי פרויקטים ספציפיים אחרים, כולל יישומי אינטרנט, תוספי Maven ואחרים.

הפעל את הפקודה הבאה להגדרת פרויקט HotelDatabase.jar:

mvn archetype:create -DgroupId=com.javaworld.hotels - DartifactId=HotelDatabase -Dpackagename=com.javaworld.hotels

עכשיו יש לך מבנה חדש ביותר של ספריית Maven 2. עבור HotelDatabaseלספריה כדי להמשיך בהדרכה.

יישום ההיגיון העסקי

כעת אנו מיישמים את ההיגיון העסקי. Hotelבכיתה היא JavaBean פשוט. HotelModelהסככה בכיתה שני שירותים: את findAvailableCities()השיטה, בערים אילו רשימות זמינות, ואת findHotelsByCity()השיטה, אשר מפרט את כל המלונות לעיר מסוימת. HotelModelכאן מוצג יישום פשוט מבוסס זיכרון :

package com.javaworld.hotels.model;

import java.util.ArrayList; import java.util.List;

import com.javaworld.hotels.businessobjects.Hotel;

public class HotelModel {

/** * The list of all known cities in the database. */ private static String[] cities = { "Paris", "London", }; /** * The list of all hotels in the database. */ private static Hotel[] hotels = { new Hotel("Hotel Latin","Quartier latin","Paris",3), new Hotel("Hotel Etoile","Place de l'Etoile","Paris",4), new Hotel("Hotel Vendome","Place Vendome","Paris",5), new Hotel("Hotel Hilton","Trafalgar Square","London",4), new Hotel("Hotel Ibis","The City","London",3), }; /** * Returns the hotels in a given city. * @param city the name of the city * @return a list of Hotel objects */ public List findHotelsByCity(String city){ List hotelsFound = new ArrayList(); for(Hotel hotel : hotels) { if (hotel.getCity().equalsIgnoreCase(city)) { hotelsFound.add(hotel); } } return hotelsFound; } /** * Returns the list of cities in the database which have a hotel. * @return a list of city names */ public String[] findAvailableCities() { return cities; } }