قالب البرنامج المساعد حنفية

قالب البرنامج المساعد حنفية

يمكنك استخدام هذا القالب لتطوير ملحقات Spigot عالية الجودة الخاصة بك باستخدام Gradle بسهولة.

راجع قالب خادم minecraft لبدء تشغيل شبكة Minecraft بسرعة في أقل من 30 ثانية.

• سمات
• إعداد البدء السريع
• إطلاق نسخة جديدة من البرنامج المساعد الخاص بك
  • الالتزام بتنسيق الرسالة
• نشر حزمة مخضرم الخاص بك
  • حول المجموعة وartifactId
  • مصادقة حزمة جيثب
• تصحيح البرنامج المساعد الخاص بك
  • انسخ البرنامج المساعد الخاص بك تلقائيا
  • تشغيل وتصحيح خادم Minecraft
• مراجع

سمات

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

• جاهز لاستخدام مشروع Gradle مع الكثير من المهام المساعدة
• الإنشاء التلقائي لـ plugin.yaml بناءً على خصائص المشروع باستخدام SpiGradle
• خادم اختبار Spigot متكامل بنقرة واحدة، ونسخ البرنامج المساعد وبدء تصحيح الأخطاء في مهمة IntelliJ
• البرنامج المساعد Gradle Shadow لشحن التبعيات المطلوبة بسهولة باستخدام البرنامج المساعد الخاص بك
• أمثلة على عمليات التكامل بما في ذلك اختبارات إطار عمل أمر التعليق التوضيحي وVault.
• إعداد اختبار JUnit 5 بما في ذلك MockBukkit وAssertJ
• تقرير تغطية كود Jacoco بما في ذلك مهمة التحميل إلى codecov
• خط أنابيب إطلاق الإصدار الدلالي متكامل تمامًا
• إنشاء سجل التغيير التلقائي بناءً على رسائل الالتزام التقليدية
• سير عمل Github Actions للإنشاء والإصدار
• نشر القطع الأثرية المخضرمة إلى حزم GitHub

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

• يصدر GitHub قوالب لطلبات الأخطاء والميزات
• المبادئ التوجيهية للمساهمة وقواعد السلوك
• شارات جميلة لإظهار مشروعك

إعداد البدء السريع

• قم بإنشاء مشروع Github جديد باستخدام هذا القالب.
• انسخ المستودع الجديد وافتحه في IntelliJ.
• قم بتحديث ملف gradle.properties وقم بتغيير المتغيرات التالية:
  • group : معرف مجموعة maven الخاص بك (على سبيل المثال: io.github.silthus)
  • pluginName : اسم البرنامج المساعد الخاص بك
  • author : اسمك
• قم بتحديث root.projectName داخل settings.gradle . سيكون هذا هو artifactId الخاص بك.
• قم بحذف CHANGELOG.md . سيتم إنشاؤه في الإصدار الأول الخاص بك.
• قم بتحديث ملف README للإشارة إلى مشروعك ومعرف مورد الحنفية.
• أعد تسمية حزمة جافا والمكون الإضافي لتتناسب مع مشروعك.
• ثم قم بتنفيذ مهمة prepareSpigotPlugins Gradle التي ستحاول تنزيل جميع تبعيات المكونات الإضافية ووضعها في debug/spigot/plugins/ .
• قم بتشغيل خادم Minecraft عن طريق تنفيذ مهمة debugPaper . سيؤدي هذا إلى تشغيل الخادم في الخلفية ويمكنك الاتصال به باستخدام عنوان localhost:25565 .
• ابتعد عن الكود :) - وبمجرد أن تصبح جاهزًا، ادفع التزامك (بأسلوب الالتزام التقليدي) إلى الإتقان.

يرجى قراءة إرشادات المساهمة قبل إرسال أي طلبات سحب أو فتح مشكلات.

ملحوظة
قد تحتاج إلى تشغيل مهمة gradle clean بعد إعادة تسمية الحزم وإعادة استيراد مشروع gradle لحل الأخطاء أثناء إنشاء plugin.yml .

إطلاق نسخة جديدة من البرنامج المساعد الخاص بك

إحدى الفوائد الرئيسية لهذا القالب هي حقيقة أنه سيُصدر تلقائيًا إصدارًا جديدًا في كل مرة يتم فيها الضغط عليه master بناءً على رسائل الالتزام الخاصة بك. يؤدي هذا إلى التأكد من إصدار المكون الإضافي الخاص بك وفقًا لإرشادات الإصدار الدلالي. لكي ينجح هذا عليك اتباع بعض القواعد البسيطة:

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

الالتزام بتنسيق الرسالة

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

مواصفات الالتزامات التقليدية هي اتفاقية خفيفة الوزن أعلى رسائل الالتزام. فهو يوفر مجموعة سهلة من القواعد لإنشاء سجل التزام واضح؛ مما يسهل كتابة الأدوات الآلية فوقها. تتوافق هذه الاتفاقية مع SemVer، من خلال وصف الميزات والإصلاحات والتغييرات التي تم إجراؤها في رسائل الالتزام.

ينبغي تنظيم رسالة الالتزام على النحو التالي:

 [optional scope]: 

[optional body]

[optional footer(s)]

يحتوي الالتزام على العناصر الهيكلية التالية لتوصيل النية إلى مستهلكي مكتبتك أو مكونك الإضافي:

• fix: التزام من النوع الذي يعمل على إصلاح الخلل في قاعدة التعليمات البرمجية الخاصة بك (وهذا يرتبط بـ PATCH في الإصدارات الدلالية).
• feat: يقدم التزام من النوع feat ميزة جديدة لقاعدة التعليمات البرمجية (وهذا يرتبط بـ MINOR في الإصدارات الدلالية).
• BREAKING CHANGE: التزام يحتوي على تذييل كسر التغيير:، أو إلحاق ! بعد النوع/النطاق، يقدم تغييرًا جذريًا في واجهة برمجة التطبيقات (يرتبط بـ MAJOR في الإصدارات الدلالية). يمكن أن يكون التغيير العاجل جزءًا من الالتزامات من أي نوع.
• الأنواع الأخرى غير Fix: وfeat: مسموح بها، على سبيل المثال @commitlint/config-conventional (استنادًا إلى اتفاقية Angular) توصي بـ build: , chore: , ci: , docs: , style: , refactor: , perf: , test: ، وغيرهم.
• قد يتم توفير تذييلات أخرى غير BREAKING CHANGE: واتباع تقليد مشابه لتنسيق git Trailer. لا يتم فرض الأنواع الإضافية بواسطة مواصفات الالتزامات التقليدية، وليس لها أي تأثير ضمني في الإصدارات الدلالية (ما لم تتضمن تغييرًا جذريًا).

قد يتم توفير نطاق لنوع الالتزام، لتوفير معلومات سياقية إضافية ويتم تضمينه بين قوسين، على سبيل المثال، feat(parser): add ability to parse arrays .

فيما يلي بعض الأمثلة:

إرسال رسالة تتضمن الوصف وكسر تذييل التغيير

 feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files

ارتكاب رسالة مع عدم وجود الجسم

 docs: correct spelling of CHANGELOG

ارتكاب الرسالة مع النطاق

 feat(lang): add polish language

إرسال رسالة تحتوي على نص متعدد الفقرات وتذييلات متعددة

 fix: correct minor typos in code

see the issue for details

on typos fixed.

Reviewed-by: Z
Refs #133

نشر حزمة مخضرم الخاص بك

سيتم نشر مكونك الإضافي تلقائيًا كحزمة مخضرمة على حزم Github بمجرد إصدار إصدار جديد.

حول المجموعة وartifactId

يتم استخدام group الملحقة بواسطة artifactId الخاص بك لتعريف مشروعك بشكل فريد عند استيراده في مشاريع أخرى. عندما تقوم باستيراد spigot في مشروعك، فإنك تستخدم المجموعة org.spigotmc متبوعة بـ artifactId spigot-api والإصدار.

تم أخذ ما يلي من دليل تسمية المخضرم الرسمي.

• يحدد groupId مشروعك بشكل فريد عبر جميع المشاريع. يجب أن يتبع معرف المجموعة قواعد اسم الحزمة الخاصة بـ Java. وهذا يعني أن الأمر يبدأ باسم نطاق معكوس تتحكم فيه. على سبيل المثال: org.apache.maven , org.apache.commons .
  إذا لم تكن تمتلك مجالًا، فيمكنك استخدام نطاق github io.github المُلحق باسم مستخدم Github الخاص بك، على سبيل المثال io.github.silthus
• artifactId هو اسم الجرة بدون إصدار. إذا قمت بإنشائه، فيمكنك اختيار أي اسم تريده بأحرف صغيرة وبدون رموز غريبة. على سبيل المثال: `maven, commons-math

مصادقة حزمة جيثب

تحتاج إلى تكوين المصادقة لحزم Github إذا كنت تريد استخدام الحزمة المخضرمة الخاصة بك في مشاريع أخرى.

1. قم بإنشاء رمز الوصول الشخصي لـ Github
2. قم بإنشاء أو تحديث gradle.properties داخل C:Users%username%.gradle بما يلي واستبدل YOUR_GITHUB_USERNAME باسم مستخدم Github الخاص بك و YOUR_PERSONAL_ACCESS_TOKEN برمز الوصول من الخطوة 1.

 gpr.user =YOUR_GITHUB_USERNAME
gpr.key =YOUR_PERSONAL_ACCESS_TOKEN

تصحيح البرنامج المساعد الخاص بك

انسخ البرنامج المساعد الخاص بك تلقائيا

يمكنك تصدير المكون الإضافي الخاص بك إلى دليل المكونات الإضافية من دليل العمل الخاص بك باستخدام مهمة Gradle PreparationSpigotPlugins . ستقوم المهمة بإنشاء المكون الإضافي الخاص بك ونسخه تلقائيًا إلى الدليل plugins/ .

تشغيل وتصحيح خادم Minecraft

يمكنك تشغيل المكون الإضافي الخاص بك أو تصحيحه باستخدام تكوين تشغيل Server من داخل IntelliJ لتنزيل خادم Minecraft تلقائيًا، وإنشائه، ونسخ المكونات الإضافية التابعة لك والتابعة إليه وبدء تشغيله في وضع تصحيح الأخطاء.

ويرجع ذلك إلى القوة الهائلة لمهام تصحيح الأخطاء في Spigradle. اكتشف المزيد على صفحة Spigradle Github.

مراجع

• Spigradle: يوفر مهامًا رائعة تجعل حياتك أسهل كثيرًا
• الإصدار الدلالي: في رأيي يجب على كل مشروع استخدام هذا!
• رسائل الالتزام التقليدية: قم بتنفيذ الرسالة بالطريقة الصحيحة