إعداد مشروع Maven متعدد الوحدات مع تبعيات مختلفة ومختلفة

Question

اسمحوا لي أن أقول هذا أولاً:أنا جديد تمامًا على Maven.ومع ذلك فقد بحثت ولكن لم أجد إجابات للسؤال التالي.لقد وجدت إجابات لأسئلة مماثلة، ولكن ليس هذا السيناريو.أو ربما أساءت فهم الإجابات ويمكن حل هذه المشكلة ببساطة من خلال إعداد وحدات متعددة.

سيكون لدي التسلسل الهرمي للتبعية التالي:

database
|  |
|  +---core
|      |  |
|      |  +---business 
|      |        |
|      |        +------App1
|      |        |
|      |        +------App2
|      |
|      +---------------App3
|
+----------------------App4

أود أن أجعله يعمل بحيث لا تؤدي التغييرات إلا إلى إصدارات جديدة لأي وحدات/تطبيقات "منبعية".هل هذه بالفعل حالة بسيطة من الإعداد المخضرم متعدد الوحدات أم أنني بحاجة إلى القيام بشيء آخر؟

Answer 1

إذا كنت تريد أن يؤدي إطلاق مكون واحد إلى إنتاج إصدار جديد لكل مشروع، فما عليك سوى استخدام مخضرم-الإصدار-البرنامج المساعد: http://maven.Apache.org/maven-release/maven-release-plugin/.

توثيق

وفقًا للوثيقة ، فإن هذا من شأنه أن:

• تأكد من عدم وجود تغييرات غير ملتزم بها في المصادر
• تأكد من عدم وجود تبعيات SNAPSHOT
• قم بتغيير الإصدار الموجود في POMs من x-SNAPSHOT إلى إصدار جديد (سيُطلب منك استخدام الإصدارات)
• قم بتحويل معلومات SCM في POM لتضمين الوجهة النهائية للعلامة
• قم بإجراء اختبارات المشروع على POMs المعدلة للتأكد من أن كل شيء في حالة جيدة
• الالتزام بـ POMs المعدلة
• قم بوضع علامة على الكود الموجود في SCM باسم الإصدار (ستتم المطالبة بذلك)
• قم برفع الإصدار الموجود في POMs إلى قيمة جديدة y-SNAPSHOT (ستتم المطالبة بهذه القيم أيضًا)
• الالتزام بـ POMs المعدلة

نظرًا لبنية الوحدات المتعددة المخضرمة، فإنها مرتبطة ببعضها البعض، وسيتم تحويل كل مشروع إلى إصدار جديد.

في بضع كلمات، هذا سوف:

• نقل الإصدار 1.0-SNAPSHOT --> 1.1-SNAPSHOT
• العلامة 1.0
• توليد 1.0.jar (أو الحرب أو أي شيء آخر)

استخدام البرنامج المساعد

بافتراض أنه تم تعريف SCM بشكل صحيح، وتكوين إدارة المستودعات والتوزيع، فما عليك سوى إضافة هذه الأسطر

<project>
  [...]
  <build>
    [...]
    <plugins>
      [...]
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-release-plugin</artifactId>
        <version>2.4.2</version>
        <!-- optional, basic format is ${project.artifactId}-${project.version}.${project.type}-->
        <configuration>
          <tagNameFormat>v@{project.version}</tagNameFormat>
        </configuration>
      </plugin>
      [...]
    </plugins>
    [...]
  </build>
  [...]
</project>

و اتصل

mvn release:prepare
mvn release:perform

الميراث مقابل التبعية

يمكنك التفكير في النهجين المختلفين اللذين يتبعهما Maven:

• الميراث، وهذا يعني الوحدات الأصلية والمتعددة/الفرعية
• التجميع، بمعنى آخر:استخدام التبعيات

في المشروع متعدد الخبراء، تتشارك جميع الوحدات النمطية، بما في ذلك الوحدة الأم، في نفس دورة الحياة.إطلاق سراح واحد يعني إطلاق سراح الجميع، وبالتالي، إطلاق سراح واحد فقط هو أمر غير منطقي.

في حالتك، لا يمكنك تعديل التطبيق من 1 إلى 3 دون التأثير على التطبيق 4.إذا كان التطبيق 4 يعتمد على التطبيق 1، فمن الواضح أن التطبيق 1 لا يمكن أن يعتمد على التطبيق 4 (غير مسموح بالمراجع الدائرية).

لذلك، تريد عزل App4 وApp1 إلى 3 دورات حياة، ويجب ألا تستخدم وحدات متعددة، ولكن فقط قم بمشاركة المشروع الأصلي، أو تسلسل هرمي من pom مثل الشركة > المشروع الرئيسي > المشروع الفرعي (وليس وحدة فرعية).بعد ذلك، ما عليك سوى إعلان التبعية بين التطبيق 4 والتطبيق 1.(...إلى app4 pom.xml)

مجرد فكرة أخرى:يبدو اسم مشاريعك ووحداتك الفرعية غريبًا.غالبًا ما يكون التسلسل الهرمي "الكلاسيكي" (مع الأخذ في الاعتبار مجال كائن أعمال متعدد لمشروع كبير):

Main Project (sometimes EAR) --> POM 
|-- Business Object / DAO --> POM
|   |-- Domain 1 --> JAR
|   `-- Domain 2 --> JAR
|-- Core (depends on BO)  --> JAR
`-- IHM / Web App (depends on core)  --> WAR

لذلك، نادرًا ما تكون قاعدة البيانات في أعلى التسلسل الهرمي.