متعددة IDE تقديم الدعم في جافا لفريق واحد

Question

ما هو أفضل وسيلة للسماح لفريق من المبرمجين لاستخدام نتبيانس، الكسوف وIntelliJ للفي نفس المشروع، وبالتالي القضاء على "التي IDE هو أفضل" السؤال.

ما ينبغي أو لا ينبغي أن يتم فحص الملفات إلى عنصر تحكم التعليمات البرمجية المصدر؟

Answer 1

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

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

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

Answer 2

حسنا، وهذا هو، والإجابة النفس السؤال جميلة.

والملفات لعدم تحقق في التحكم بالمصادر هي الملفات التي لها علاقة مع بيئات التطوير أنفسهم.

واتركه للمطورين لتوليد هذه الملفات.

إذا كنت تستخدم مخضرم، فإنه يمكن إنشاء ملفات مثل .project الكسوف و.classpath بالنسبة لك. الكسوف بشكل عام من السهل جدا للاستخدام مع بنية الملفات الأساسية (مع خيار Java Project جديد).

وأعتقد مخضرم يحظى بدعم نتبيانس كذلك، ولست متأكدا حول IntelliJ للبالرغم من ذلك.

وموقع مخضرم هو maven.apache.org .

Answer 3

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

ولقد فعلت هذا مع العديد من بيئات التطوير المختلفة، وأنا لم أرى صراع اسم الملف.

في الواقع، حتى عندما يستخدم فقط لمطور واحد في IDE خاص، هو أن له / مصلحتها إلى الإصدار ملفات الدعم، للسبب نفسه الذي نسخة الملفات الأخرى في بيئة التطوير الخاصة بك: التاريخ، diffing والتعليقات ، وما إلى ذلك.

Answer 4

لالكسوف، التي من شأنها أن تكون ملفات .classpath و.project.

وفريقي يستخدم مخضرم، ويشجع المطورين من التحقق في ملفات الكسوف محددة. لأنها يمكن أن تتولد من مخضرم، هذه الملفات هي زائدة عن الحاجة.

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

Answer 5

وهناك العديد من الاعتبارات عند استخدام من toolsets متعددة ضمن فريق المشروع نفسه. على سبيل المثال، فريق بلدي لديه مطوري جافا باستخدام IntelliJ للومعظم الواجهة الأمامية للمطورين (JSP / CSS / HTML) باستخدام الكسوف. نحن في عملية ترحيل المستخدمين الكسوف لIntelliJ للبسبب بعض الإضافات IntelliJ للأن وضعنا التي توفر الدعم الموسع لبيئتنا. نحن لسنا بصدد تطوير الإضافات لمنصات متعددة، لذلك نحن على توحيد IntelliJ للفي جميع المجالات.

في ناحية ملفات معينة، أستطيع أن أتحدث إلى IntelliJ لل. لقد دققت في ملفات .ipr لدينا وملفات .iml لدينا. لا تحقق في ملفات .iws. إذا كان لديك أيضا للمستخدمين الكسوف، تكوين مشروع IntelliJ لللقراءة / مخزن معلومات التبعية في ملف .classpath والالتزام الذي لVCS الخاص بك.

Answer 6

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

وماذا يعني في نهاية المطور هو أنها لا ينبغي أن <م> ارتكاب التغييرات الخاصة بهم إلى ملفات IDE. كل شيء آخر (على سبيل المثال، SRC، اختبار، ليب وهكذا دواليك) يصبح مجموعة أننا عادة تحديث وارتكاب كل يوم.

وصالح الجانب هو أننا ألغت تماما الحروب IDE هنا: نتبيانس الكسوف ويعيش الناس في وئام تام (النظر شزرا على الناس IntelliJ لل، ولكن مهلا ...؛ -)

Answer 7

لمزيد من التعليقات والإجابات حول هذا الموضوع راجع هذا السؤال (كيف يمكنك التعامل مع بيئات التطوير جافا مختلفة وإس؟)

Answer 8

ونحن إعادة تسمية الملفات IDE لدينا الاعارة مع .deletethis تمديد اضافي أو ما شابه ذلك. عندما يتحقق شخص جديد من المشروع، فإنها ببساطة تجريدها من تمديد إضافي وهي جيدة للذهاب. بهذه الطريقة نتجنب الصراعات التحكم بالمصادر مع ملفات المشروع من الناس قرص بيئاتها. وكنت لا داعي للقلق حول تعليم المطورين الجديد لعدم تحقق في تلك الملفات.

Answer 9

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

إذا واحدة من بيئات التطوير يحدث أن تكون RAD (على أساس الكسوف)، وهناك مجلد كامل يسمى .settings التي كنت لا تريد أن تدرج في SCM.