كيف أقوم بإعداد مشروع Maven متعدد الوحدات بشكل صحيح مع دورات إصدار منزلقة

Question

أحاول التوصل إلى أفضل طريقة لإعداد مشروع Apache Maven متعدد الوحدات الخاص بنا بطريقة تسمح بدورات إصدار متباينة للوحدات، ولا تسبب مشكلات التبعية عند تصحيح أخطاء المشروع.

لدينا حاليًا إعداد على غرار:

• نظام كبير@1.2
  • parent-1.1-SNAPSHOT
  • الوحدة النمطية a@1.4-SNAPSHOT
    • برعايةparent@1.1-SNAPSHOT
  • الوحدة النمطية b@1.3-SNAPSHOT
    • برعايةparent@1.1-SNAPSHOT
    • يعتمد على @1.1
  • الوحدة النمطية c@1.1-SNAPSHOT
    • برعايةparent@1.1-SNAPSHOT
    • يعتمد على @1.2
    • يعتمد على ب@1.1

تحتوي التبعيات المعلنة في الوحدتين b وc على الحد الأدنى من الإصدار المطلوب لتجميع الوحدة، وهو ليس بالضرورة الإصدار الحالي من الوحدة، أو إصدار الوحدة التي يتم نشرها.

من منظور البناء، يعمل هذا بشكل جيد، يمكن إصدار/تحديث كل وحدة حسب الحاجة، ولكن عند محاولة تصحيح أخطاء التطبيق المنشور ضمن IntelliJ IDEA (الإصداران 8 و9 EAPs) بعد فتح المستوى الأعلى، تقرر IDEA أنه منذ أن أعلنا الاعتماد على a@1.2، في أي وقت ندخل فيه إلى أحد فئات a، يجب أن يفتحه من a-1.2-sources.jar بدلاً من مصادر a@1.4 الحالية في المشروع.ومما يزيد الأمر تعقيدًا حقيقة أن الدخول إلى أي من فئات b يأخذنا إلى b@1.1 بدلاً من b@1.3.

كانت محاولتي الأولية للتغلب على هذه المشكلة هي الإعلان عن أرقام الإصدارات في قسم DepenencyManagement الخاص بـ pom الأصلي وجعل الوحدات الفرعية ترث الإصدار فقط.لقد نجح هذا إلى حد حل مشكلة تصحيح IDEA حيث يمكن لقسم إدارة التبعية توجيه الجميع إلى إصدارات -SNAPSHOT الحالية.

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

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

لدي شك في أنني أفتقد شيئًا ما، وأن مجموعة من إدارة التبعية ونطاقات الإصدار قد تلبي المتطلبات على الرغم من أنني لم أر بعد نطاقات الإصدارات تعمل بشكل صحيح.

هل هناك طريقة أفضل؟طريقة مناسبة؟

Answer 1

كان الحل النهائي/العملي الذي انتهى بنا الأمر باستخدامه مشابهًا إلى حد ما لما بدأنا به.يبقى هيكل المشروع الفعلي كما هو:

• نظام كبير@1.2
  • parent-1.1-SNAPSHOT
  • الوحدة النمطية a@1.4-snapshot أو الوالدين بواسطة parent@1.1-snapshot
  • الوحدة b@1.3-snapshot o الوالدين بواسطة parent@1.1-snapshot o تعتمد على a@1.1
  • الوحدة c@1.1-snapshot o الوالدين بواسطة parent@1.1-snapshot o يعتمد على a@1.2 o يعتمد على b@1.1
  • التوزيع a@1.2-SNAPSHOP

لكن الاختلافات الرئيسية هي أن:

• الوحدة الأصلية لا تتضمن أي إصدارات من التحف المشروع
• تعلن الوحدات الفردية بشكل كامل عن تبعيات مشروعها وتحدد نطاق الإصدار، على سبيل المثال.[1.0.0,1.1.0)
• تبدأ جميع الوحدات هناك دورات رقم الإصدار من .1، أي 1.0.1-SNAPSHOT، وهذا يسمح بتغطية نطاق الإصدار من خلال اللقطات الأولية (1.0.0-SNAPSHOT أقدم من 1.0.0 نهائي، لذلك لم يتم تضمينه).
• يحدد توزيع pom (غير موضح في البداية في السؤال) ملف بالضبط الإصدار الذي سيتم نشره/إدراجه في إصدار محدد.
• احذف جميع لقطات المشروع -SNAPSHOTS من مستودع maven المحلي عند الإصدار بحيث يتم إصدار نطاقات الالتقاط فقط (أو استخدم -Dmaven.repo.local=/tmp/sometemprepo للحصول على مستودع محلي جديد)

وهذا يجعل كل وحدة أكثر استقلالية ويمنحنا الحرية لإصدار ونشر إصدارات جديدة من عناصر مشروعنا بأقل قدر من الضجة.

Answer 2

أوصي بعدم جعلها وحدات نمطية، ولكن جعل POMs الخاصة بها مستقلة.بهذه الطريقة لا داعي للقلق بشأن محاولة تلبية تبعيات POM الأصلية.نظرًا لأنه تم إصدارها بشكل مستقل، فيجب أن يكون لديها نماذج كائنات مشروع مستقلة.فكر في Apache Commons كقالب.

Answer 3

أعتقد أن مشكلة IDEA تنشأ لأنك تستخدم POM الجذر في البنية المصدر الخاصة بك للقيام بأمرين عادة ما يكونان متنافيين في Maven.أنت تستخدم أولاً POM كموقع لتخزين معلومات التكوين العامة لمشاريع Maven غير ذات الصلة (من منظور البناء).ثانيًا، أنت تستخدم POM كمجمع للبناء الخاص بك.يمكنك أن تفعل كل واحد من هذه دون أن تفعل الآخر.

كما قال روب، قم بإزالة الوحدة الخاصة بك أ، ب، وما إلى ذلك.المشاريع من قسم الوحدات في POM الخاص بك.ثانيًا، انقل POM الأصلي الخاص بك إلى الدليل الخاص به لأنه في الحقيقة شقيق للوحدات الأخرى فيما يتعلق بعملية الإنشاء والإصدار.بالطريقة التي لديك بها الآن، فهي أكثر من مجرد والد/مجمع.

الطريقة التي تستخدمها الآن أيضًا لا تصلح لوضع علامات على كل وحدة وإصدارها على حدة، حيث من المحتمل أن تتضمن علامة POM الأم الخاصة بك جميع المجلدات الفرعية للوحدة دون داع.

ستبدو بنية الملف الخاص بك كما يلي:

• الأبوين
  • pom.xml
• الوحدة أ
  • pom.xml
• الوحدة X
  • pom.xml

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

Answer 4

من المؤكد أنها تبدو وكأنها وحدات منفصلة.ما هي الفوائد التي ستجنيها من دمجهم معًا إذا كان لديهم تبعيات مختلفة، حتى داخل المشروع متعدد الوحدات؟