نصيحة بشأن أداة بناء Java جيدة ، مدمجة جيدًا مع Eclipse
https://stackoverflow.com/questions/3186392
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
أنا أعمل في فريق صغير (3 أشخاص) على عدة وحدات (حوالي 10 حاليًا). أصبح تجميع إصدارات البناء وتكاملها وإدارتها أكثر شاقة. أنا أبحث عن أداة بناء / تكامل جيدة لاستبدال / إكمال النمل.
فيما يلي وصف لبيئة التطوير الحالية لدينا: - عدة وحدات اعتمادًا على كل من الجرار على الطرف الثالث - قد يصدر بعضها الجرار وبعض حروب التصدير وبعض الجرار المستقلة للتصدير (مع الدهون) - Javadoc بالنسبة لهم جميعًا - نحن نعمل مع Eclipse - نص ANT مخصص لكل وحدة. العديد من المعلومات المتكررة بين تكوين Eclipse ونصوص ANT. على سبيل المثال ، بالنسبة إلى الدهون المستقلة ، قمنا بإدراج جميع التبعيات المتكررة ، في حين أنه من الناحية المثالية ، يمكن استيراده بوضوح من تكوين Eclipse. - يتم إصدار رمز المصدر باستخدام SVN
إليكم ما أود أن أفعله أداة تكامل مثالية من أجلي:
تلقائي الإصدارات وإصدار الوحدات النمطية. من الناحية المثالية ، يجب أن تكتشف أداة التكامل ما إذا كانت هناك حاجة إلى إصدار جديد. على سبيل المثال ، إذا كنت أرغب في إصدار مشروع A يعتمد على المشروع B ، وإذا قمت بإجراء تغييرات صغيرة على المشروع B محليًا ، فيجب أن تصدر أداة التكامل أولاً إصدارًا جديدًا من B هو - هي.
الاندماج بقوة مع Eclipse ، حتى يتمكن من الحصول على التبعيات بين الوحدات النمطية و Libs من طرف ثالث من تكوينها. راجع للشغل ، أود الاستمرار في تكوين مسار البناء مع Eclipse دون تحديث بعض الأشياء الأخرى ".xml". لقد رأيت أن Gradle يمكنه إنشاء ملفات مشروع Eclipse من تكوينها ، لكن النظير سيكون رائعًا.
تمكين التنمية "المباشرة" والشفافة في المشاريع المحلية. أعني أنني غالبًا ما أقوم بإجراء تغييرات صغيرة على المشاريع الأساسية / المشتركة أثناء تطوير المشاريع الرئيسية / "الأوراق". أرغب في الحصول على تغييراتي على المشاريع الأساسية المتاحة على الفور لمشاريع الأوراق دون الحاجة إلى نشر (حتى محليًا) الجرار في مشاريعي الأساسية.
قم بتخزين جميع إصدارات الإصدارات من الوحدة النمطية على خادم خارجي. أبسط (مجلد الأسهم / WebDAV) سيكون الأفضل. ستكون صفحة ويب لطيفة مع قائمة الوحدات النمطية والتحف المسقلة رائعة أيضًا.
لقد نظرت حولي لأشياء كثيرة. من ant4eclipse (لدمج تكوين Eclipse في البرنامج النصي الخاص بي) ، إلى أدوات Maven / Ivy / Gradle.
أنا مشوشة قليلا. إليكم ما فهمته حتى الآن: - Maven أداة رائعة / كبيرة ، ولكنها صلبة إلى حد ما وتجبرك على الانحناء إلى هيكلها ومفاهيمها. يعتمد على الوصف وليس على البرمجة النصية. إذا خرجت من المسار ، فيجب عليك تطوير مكونات إضافية تملكها. - Ivy أقل قوة من Maven ، فإنه يتعامل مع أشياء أقل ولكنه أكثر مرونة. - Gradle هو بين. إنه غرض عام. إنها تتيح تكوين البرمجة النصية وكذلك "القائمة على الاتفاقية". يدمج النمل ويمتدها.
لذلك في هذه المرحلة ، أبحث عن شهادات فعلية من المستخدمين الحقيقيين. ما هي الأدوات التي تستخدمها؟ كيف ؟ هل لديك نفس الاحتياجات مثلي؟ هل تخفف حياتك أو تصل إلى الطريق؟
هل هناك عينة من بعض حالات الاستخدام ، أو هياكل عظمية في مساحة العمل التي يمكنني استخدامها كنقطة انطلاق لمعرفة ما هي هذه الأدوات القادرة؟
آسف لطول هذه الرسالة. وشكرا مقدما لكم نصيحة.
أطيب التحيات،
رافائيل
المحلول
أتمتة الإصدارات وإصدار الوحدات النمطية (...)
مفاهيم الإصدار والمستودع مدمجة مع Maven ويمكن أن تناسب هنا.
مافن يدعم التبعيات لقطة. عند استخدام لقطة ، ستحاول Maven بشكل دوري تنزيل أحدث لقطة متوفرة من مستودع عند تشغيل بناء. عادة ما يتم استخدام اللقطة عندما يكون المشروع تحت التطوير النشط.
يدعم Maven 2 أيضًا نطاقات الإصدار (لا أوصيهم حقًا ولكن هذه قصة أخرى) تسمح على سبيل المثال بتكوين A للاعتماد على الإصدار [4.0,) من B (أي إصدار أكبر من أو يساوي 4.0). إذا قمت ببناء وإصدار نسخة جديدة من B ، فستستخدمها.
دمج بقوة مع الكسوف
ال m2eclipse يوفر البرنامج المساعد التزامن ثنائي الاتجاه مع Eclipse.
تمكين التنمية "المباشرة" والشفافة في المشاريع المحلية.
يدعم المكون الإضافي M2Eclipse "دقة مساحة العمل": إذا كان المشروع A يعتمد على المشروع B وإذا كان المشروع B في مساحة العمل ، فيمكنك تكوين A للاعتماد على مصادر B وليس على B.Jar (هذا هو الوضع الافتراضي إذا لم أكن خاطئ - ظلم - يظلم). لذلك سيكون التغيير على مصادر B مرئية مباشرة ، دون الحاجة إلى بناء B.Jar.
قم بتخزين جميع إصدارات الإصدارات من الوحدة النمطية على خادم خارجي.
كما ذكرنا سابقًا ، يعد هذا في الواقع مفهومًا رئيسيًا لـ Maven (ليس لديك حتى الخيار) والنشر من خلال ملف: // أو Dav: // كلاهما مدعوم.
خلاصة القول ، إن Maven ليس (ربما) المرشح الوحيد ، لكنني متأكد من أنه سيحقق:
- مشروعك ليس غريبًا أو معقدًا ، لا يوجد شيء يخيف من وصفك (من المحتمل أن يكون هناك حاجة إلى بعض إعادة بناء الهيكل ولكن لا ينبغي أن يكون هذا أمرًا كبيرًا).
- يجلب Maven أيضًا سير عمل بناءً على أفضل الممارسات.
- يوفر M2Eclipse تكاملًا قويًا مع IDE.
لكن مافن لديه بعض منحنى التعلم.
نصائح أخرى
أدوات CI؟ بالنسبة لي ، هناك واحد فقط: هدسون سي.
لقد قمت بإعداد بيئة تطوير البرمجيات لجافا مرة واحدة ، مع المكونات:
- Eclipse IDE
- زئبقي
- Bugzilla
- مافن
- Nexus
- هدسون سي
وبعض apache ، mysql ، php ، perl ، python ، .. للتكامل.
لم يتم دمج Hudson مع Eclipse وكان ذلك عن قصد ، لأنني أردت البناء على خادم منفصل. لجميع الأدوات الأخرى ، كان لدي تكامل تقاطع مثالي (مثل: Myllyn on Eclipse للتحدث مع Bugzilla ، M2Eclipse لاستخدام Maven Eclipse ، والكثير من الإضافات لـ Hudson ، ...) ...)
لقد بدأنا في دمج Gradle في عملية الإنشاء الخاصة بنا ، ويمكنني أن أضيف إلى الإجابات المنشورة بالفعل أن Gradle ستعمل أيضًا. إن افتراضاتك صحيحة في الغالب ، و Gradle أكثر قبالة الكفة ، ولكنها قوية وتتيح البرمجة النصية ومثل هذا البناء نفسه. يبدو أن معظم الأشياء التي يمكن أن يفعلها Maven ، كما يفعل Gradle.
الآن لنقاطك الفردية:
الإصدار: يدعم Gradle خرائط التبعية ، والإصدار ، وإذا أضفت في خادم CI ، فيمكنك تشغيل بنيات تلقائية/معتمدة. على سبيل المثال ، جميع "التسليمات" الخاصة بنا تقريبًا هي. الحواس ، ولكن لدينا العديد من الكود libs (.jars) وواحد قابلة للتنفيذ. تكوين واحد هو جعل الحروب و "جار الدهون" يعتمد على الرمز المشترك. بعد ذلك ، عندما يتم تحديث libs المشتركة ، تصطدم الإصدارات الموجودة على libs المشتركة ، واختبار المشاريع المستهلكة ، ثم استخدم قدرة هدسون على إطلاق المشاريع التي تعتمد على إعادة نشرها. هناك طرق أخرى ، ولكن يبدو أن هذا يعمل بشكل أفضل بالنسبة لنا ، في الوقت الحالي.
دمج بقوة مع الكسوف: أنت على حق ، يمكن لـ Gradle إنشاء ملفات Eclipse. نميل إلى استخدام مهمة EclipseCP (لتحديث .classpath) فقط بمجرد أن نذهب ، مع تغير احتياجات ClassPath فقط. إنه نوع من الغريب (يمسك JRE الافتراضي ، لذا تأكد من أنه صحيح ، لا يضيف تصدير = "صحيح" إذا كنت في حاجة إليه) ، ولكنه يحصل على 99 ٪ من الطريق هناك.
تمكين "حي" وشفاف في المشاريع المحلية: هذا واحد لست متأكدًا منه. لقد اخترقت فقط حول Gradle في هذه الحالة ؛ من خلال إزالة القطع الأثرية في المشروع المستهلك وتمييز المشروع المشترك على هذا النحو في Eclipse ، ثم عاد بعد ذلك.
قم بتخزين جميع إصدارات إصدارات الوحدة النمطية على خادم خارجي: يتم دعم الأساليب البسيطة والعديد من المقاهي ، على غرار Maven.
فيما يتعلق بالأمثلة ، فإن مستندات Gradle جيدة ، وكذلك المشاريع المثال التي تأتي مع Zip الكامل. سوف يستعدونك ويعملون بسرعة إلى حد ما.
إلقاء نظرة على النمل آيفي. http://ant.apache.org/ivy/
لا توجد رصاصات فضية ، ولكن في تجربتي ، يعد Maven أداة رائعة لإدارة المشاريع. أنا شخصياً أود استخدام comibnation من التخريب (للتحكم في الإصدار) و Maven (لإدارة المشروع/الإنشاء) وهدسون (للبناء/التكامل المستمر).
أجد أن الاتفاقية التي قدمتها Maven مفيدة حقًا لتبديل السياق ، وهي رائعة لإدارة التبعية. قد يكون الأمر محبطًا إذا لم تكن الجرار في المستودعات ، ولكن يمكنك تثبيتها محليًا وعندما تكون جاهزًا ، يمكنك استضافة مستودعك الخاص الذي يعكس الأماكن الأخرى. لقد مررت بتجربة جيدة باستخدام sonar.nexus بواسطة http://www.sonatype.com/ . كما أنها توفر كتابًا مجانيًا للتميز لتبدأ.
قد يبدو الأمر مبالغًا فيه الآن ، لكن إعداد بيئة بناء / اختبار / إصدار جيدة الآن ، سيدفع أرباحًا لاحقًا. من الصعب دائمًا التغلب على الرجعية ، وهو شيء يمكنك تكراره بسهولة.
أخيرًا ، أفضّل تكامل NetBeans لـ Maven ، لكن هذا أنا فقط :)
بعض موضوعاتك هي جزء من إدارة النشر والإصدار.
يمكنك التحقق من منتج مثل: Xebia Deployit
(مع ال الطبعة الشخصية وهو مجاني)
