يمكن أن تحرر الاستفادة باسكال من شيء مثل اباتشي مافن؟

Question

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

• الافراج عن مكتبات المصادر المفتوحة المعتمدة من أجل باسكال مجانا (أو دلفي) في مستودع في مينفن عام
• تضمين بيانات التعريف في هذا المستودع الذي يحتوي على معلومات التبعية
• استخدم Maven في سطر الأوامر لتنزيل مكتبة المصدر المفتوح من المستودع العام، وحل تلقائيا جميع التبعيات
• المستودعات المحلية، التي تعمل كوكالات، يمكن استخدامها لذاكرة التخزين المؤقت التي تستخدمها الثنائيات بشكل متكرر
• إن توليد الاختباري التلقائي والتحقق (المقدمة من Maven) من شأنه أن يقلل من خطر تنزيل الثنائيات التالفة
• يمكن تقديم شفرة المصدر وحتى ملفات الوثائق مع الثنائيات
• يمكن تقديم الثنائيات أو بدون معلومات تصحيح
• خوادم التكامل المستمر مثل هدسون, teamcity. أو مثبت السرعة يمكن استخدامها لبناء مشاريع كلما تم تقديم التغييرات إلى نظام التحكم المصدر وإخطار المطورين حول إنشاء أخطاء

قد تكون هذه الطريقة في إدارة التبعية مفيدة للغاية لمشاريع مفتوحة المصدر التي تستخدم العديد من مكتبات الطرف الثالث مع تبعيات معقدة. سوف يتجنب النزاعات النموذجية الناجمة عن استخدام الإصدارات الخاطئة.

بالنسبة للمطور، سيتم تخفيض سير العمل لتحرير وبناء مشروع إلى الحد الأدنى:

• الخروج مصدر المشروع من نظام التحكم الإصدار الداخلي
• تحرير ملف (ملفات) المصدر
• يركض mvn package لتنزيل جميع مكتبات الطرف الثالث المطلوبة تلقائيا (وحدات مسبقة الرأس) إذا لم تكن بعد في مستودع محطة العمل المحلية
• تجميع وتشغيل

الملف الإضافي الوحيد ل Apache Maven وهو مطلوب في مجلد المشروع هو ملف Pom.xml الذي يحتوي على معلومات المشروع.

عدل

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

ميزات مافن مدرجة في http://maven.apache.org/maven-features.html.

---

تحديث:

يمكن أن تكون حالة استخدام واحدة هي بناء Lazarus، حيث تقوم Maven بتنزيل جميع المكتبات المطلوبة واستدعاء المحول البرمجي مع وسيطات مسار البناء الضروري. سيتم نشر التغييرات في التبعيات على مستويات أقل تلقائيا حتى بناء الوالدين.

الفوائد المحتملة:

• وقت أقل مطلوب لإنشاء محطة عمل جديدة، لا تركيب يدوي لمكتبات الطرف الثالث المطلوبة
• أخطاء أقل ناتجة عن إصدارات مكتبة خاطئة، والكشف عن تعارضات الإصدار (على سبيل المثال إذا كانت المكتبات تعتمدان على إصدارات مختلفة من مكتبة ثالثة)
• يمكن إضافة القطع الأثرية التي تم إنشاؤها الداخلية إلى مستودع MAVEN المحلي ومشاركتها بين المطورين والمشروع، والتخزين المركزي لجميع القطع الأثرية مع البيانات الوصفية
• المباني غير قابلة للتكرار، فقط باستخدام نفس ملف البيانات الوصفية والمشروع (Pom.xml)
• يمكن أن تقلل من وقت التطوير وزيادة استقرار المشروع

تحديث رقم 2: FPMake

ال FPMake. يبدو أن إنشاء نظام لباسال المجاني أداة مع الكثير من الإمكانات، في العديد من التفاصيل مماثلة جدا ل Maven:

• FPMake هو نظام البناء القائم على Pascal تم تطويره وتوزيعه مع FPC
• FPMAKE توحيد المبنى عن طريق تحديد بعض الحدود مثل الدلائل القياسية
• الامر fppkg <packagename> سوف ننظر في قاعدة بيانات للحزمة، واستخرجها، ثم ترجمة FPMake.pp وتشغيله
• لديها أهداف البناء القياسية (نظيفة، بناء، تثبيت، ...)
• يمكن إنشاء ملف "بيان" مناسب للاستيراد في مستودع (مثل mvn deploy أو mvn install)، البيان هو ملف XML الذي يبدو مشابها للغاية ب Pom.xml في Maven:

ملف بيان fpmake:

      <packages>
        <package name="my-package">
          <version major="0" minor="7" micro="6" build="1"/>
          <filename>my-package-0.7.6-1.zip</filename>
          <author>my name</author>
          <license>GPL</license>
          <homepageurl>http://www.freepascal.org/</homepageurl>
          <email>myname@freepascal.org</email>
          <description>this is the package description</description>
          <dependencies>
            <dependency>
              <package packagename="rtl"/>
            </dependency>
          </dependencies>
        </package>    
      </packages>

Answer 1

يعمل Freepascal على نظام حزمة من تلقاء نفسه في التقاطع بين نمط المنافذ APT-Get و FreeBSD. (تحميل مصدر / إنشاء / تثبيت تلقائيا)، يسمى FPPKG. لكن العمل قد توقف. الناس يستثمرون الوقت هم عنق الزجاجة، وليس الناس الذين يرغبون في اختيار الأدوات.

بقدر ما يذهب Maven، لا أحب الأدوات المساعدة التي تحتاج إلى تركيب أوقات تشغيل خارجية ضخمة. قد تكون على ما يرام لتطبيق كبير كبير (مثل Open Office)، ولكن ليس من أجل Util.

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

بعض المشكلات النموذجية عند تقديم تقنية جديدة في مشروع كإليفة FPC، ولماذا يتميز باتجاه الأدوات الخاصة به:

• بحاجة إلى تدريب 20+ الملزى في الوقت المناسب.
• لغة البرمجة الشائعة الوحيدة التي يمكن أن تفترضها مجانية باسكال. حتى لا يمكن اتخاذ إجراءات ديلفي الداخلية أمرا مفروغا منه لمعرفة أن العديد من الالتفافية جاءت مباشرة إلى FPC أو حتى لا تزال عبر TP أو Mac Pascal)
  • من الواضح أن يجعل شيئا مع الإضافات في لغة مختلفة مزعجة.
• سيناريو باش هو الثاني وثيق. (ز) جعل الثالثة، ولكن بالفعل حجم أقل.
• جميع الخوادم هي * مثل Nix - مثل (FreeBSD، OS X، Linux)، ولكن ليس كل شيء تشغيل Apache. (مثل مرآة FreeBSD الخاصة بي يعمل xshttpd)
• يجب أن يكون شخص ما الأكثر دراية موافقة مخصصة لفترة طويلة. إصلاح المشاكل، تحديث / إجراء الهجرة وما إلى ذلك أكثر واقعية لأسباب واضحة.
• الألم الرئيسي هو توزيعات Linux (و FreeBSD إلى درجة أقل)، ومعظم صفقات الحزم * NIX غير قادرة على تثبيت أكثر من ". onconfigure؛make؛make وبعد
  • تعبئة التوزيع في FPC / Lazarus كانت دائما مهمة، ولا تزال تتزايد
  • تحتوي جميع التوزيعات على قواعد خاصة خاصة بها حول البيانات الوصفية والسباق وكيفية نشر المصادر. لا سيما debian / ubuntu البيروقراطية والبطيئة للغاية.
  • معظمهم لا يحبون المثبتات التلقائية الطرف الثالث على رأس أنظمتهم (لأن هذا يتجاوز سيطرتهم التضاعف)

يؤدي كل هذا إلى الممارسة الفعالة التي تملك الأدوات في Pascal بأقل قدر من العمل البرمجي الأفضل. بعض الأدوات المستخدمة:

• يتم استخدام GMAKE بشكل أساسي في معلمة عملية البناء على مستوى لكل دليل، وهو خليفة، FPCMAKE (ليس حقا مشتق على الرغم من الاسم) قد بدأ، ولكن الهجرة لم تكتمل.
• يمكن استخدام اللاتكس ومطاط إلى تحويل HTML (TEX4HT، ولكن Debian يستخدم Hevea) في مبنى الوثائق (الوثائق غير المكتبة)
• موقع المجتمع (خادم Netscape Community الذي يستخدم Scripting TCL، خادم تطبيقات معقدة ثقيلة) كان مشكلة منذ أن بدأت، ولكن بشكل خاص مؤخرا منذ أن أصبح المشرف أقل نشاطا.
• لقد كانت Mantis مشكلة (خاصة وحدة البريد الإلكتروني ستتحطم أو تعرج الخادم بسبب الحجم)، لكنه تم تخفيفه في الشكل أثناء التحديثات المتعاقبة والعمل الشاق لعدة تيلز لازاروس. حاليا هو وضع عمود وردي.
• Lazarus.Freepascal.org PhpBB Forum Otoh غير مؤلم نسبيا لأن الكثير من الأشخاص الأصغر سنا يعرفون كيفية التعامل معها.
• الشيء نفسه ينطبق على الإصابات (على الرغم من أن النطاق الأكثر تقدما يحتاج إلى بعض التعديل، وليس الجميع في عمق INS و OURGESS

إذا كان شخص ما جادا حقا في مافن، فسأطلب منه:

• ل انتقاد التحقيق في استخدام المشروع. بطريقة ملموسة للغاية، مع تقديرات الجدول والوقت. مستوى الطيور العين "كل شيء ممكن" نظرة عامة لا قيمة لها ESSENTIALY.
• إعطاء بعض الفكر في التغيير في المستقبل من التقنيات المستعملة. يتم استبدال كل تقنية في نهاية المطاف، حتى في المنزل، في 18 سنة + مشاريع. يجب ألا تجعل التكنولوجيا الجديدة هجرات مكونات البنية التحتية الأخرى الصعبة أو المعنية. التكنولوجيا الجديدة لإنهاء جميع التقنيات الجديدة غير موجودة.
• تقديم خطة هجرة. غالبا ما تكون الترحيل غير متقدمة وتقليلها.
• وفي النهاية، هناك دائما سؤال 1000000 يورو، الذي سيفعل الصيانة اليومية؟

ضع في اعتبارك أنه في شركة تقوم بها فقط الشخص المسؤول عن خادم التطبيق. ولكن في بيئة غير رسمية، هذا أكثر صعوبة، على المدى الطويل على المدى الطويل، لأن حياة الناس والمهن والوقت الذي يقضيه المشروع.

Answer 2

يبدو وكأنه خطة مثيرة للاهتمام، ولكن مجتمع دلفي (و FPC أكثر من ذلك، كنت أتخيل!) القيم المكتبات كمصدر أكثر بكثير من المكتبات المعتمدة. الإجماع العام هو أن أي شخص يستخدم مكتبة ثنائية فقط هو أحمق، لسببين: لا يمكنك إصلاح أي أخطاء تجده فيها، وسوف تقطع التحويل البرمجي التوافق.