.classpath та .project - перевірити контроль версій чи ні?

Я запускаю проект Java з відкритим кодом, який складається з декількох модулів у дереві залежностей. Усі ці модулі є підкаталогами у сховищі диверсій. Для новачків нашого проекту є велика робота, щоб налаштувати все це вручну в eclipse.

Не всі наші розробники використовують eclipse. Тим не менше, ми розглядаємо можливість просто перевірити файли .classpath та .project, щоб допомогти новачкам розпочати роботу. Це гарна ідея? Або це може призвести до постійних конфліктів у цих файлах? Чи існує альтернативний спосіб спростити створення проекту на eclipse?

Остаточно так, як я вже сказав у " Чи тримаєте ви свої файли проекту під контролем версій? "

"Завантажте, налаштуйте, ідіть".

Але ... це насправді справедливо лише для останніх налаштувань Eclipse3.5, де шляхи побудови підтримують відносні шляхи :

І Eclipse3.6 було б краще, оскільки він підтримує відносні шляхи для змінних шляху в Linked Resources:

(з 3.6M5)

Безумовно, ні - загалом це жахлива ідея розповсюджувати файли проектів за допомогою диверсії. Тим більше, що хтось може змінити їх якось дивно. Хороша сторінка в документації проекту - набагато краща ідея. Наш проект також має безліч модулів та складну настройку. Ми створили сторінку злиття, яка описує, як розпочати роботу з проектом на кожному IDE популера - IntelliJ, Eclipse, NetBeans. Файл README у Subversion містить ту саму інформацію.

Я голосую проти, але це тому, що я, як правило, генерував би ці файли з maven

З мого досвіду, за винятком обмежених випадків, коли задіяні суто локальні налаштування, все повинно знаходитися під контролем джерела. Закон контролю джерел полягає в тому, що все, що проштовхують, слід очікувати на роботу тих, хто витягує. На жаль, затемнення часто спричиняє такі речі .classpath:

    <classpathentry kind="con" 
      path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.launching.macosx.MacOSXType/Java SE 7"/>

Отже, на моєму Mac це працює, і, можливо, хтось на Mac має такий самий JRE, але це не спрацює ні для кого іншого.

Крім того, немає простого способу обійти це. Eclipse завжди додасть це. Я ХОЧУ мати там файл .classpath, оскільки в нашій папці lib є деякі сторонні JAR-файли, де ми дбаємо про встановлення версій, тому залишаємо їх там, щоб нові розробники не повинні їх отримувати . Ми переходимо до керованої системи, але все ще зареєструвались керовані + некеровані залежності. Це означає, що всі розробники просто повинні переконатися, що два каталоги знаходяться в них .classpath. Але це краще, ніж виправляти свій JRE кожного разу, коли ви тягнете, і змінювати свій .classpath кожного разу, коли ви фіксуєте.

Eclipse робить для вас ще деякі приємні речі. Файл .project, як правило, однаковий у всіх примірниках, тому включіть його. Але найкраще у контролі джерела для eclipse - це налаштування Run Configurations. На вкладці "Загальне" у діалоговому вікні "Запустити конфігурації" збережіть конфігурації, щоб вони з'явилися для ваших колег у списках вибраного для налагодження та запуску. Для мене купа .launchфайлів потрапляє в .settingsкаталог, тому ми всі можемо ними користуватися.

Тому я кажу: .settingsкаталог переходить у вихідний контроль для налаштувань запуску (крім * .prefs)

.classpath залишається осторонь

.project заходить.

Я хотів би перевірити ці файли, щоб максимально спростити старт для нових користувачів. У кращому випадку користувач повинен перевірити проект і мати можливість запускати його без додаткових знань. Для цих файлів правила такі самі, як і для інших файлів у проекті: обробляйте їх обережно. Не слід розміщувати абсолютні штрихи у вихідному коді, а також у файлах конфігурації.

Якщо файли перевіряються таким чином, що проект працює з нуля, не повинно бути багато сил, щоб змінити їх.

Я рекомендую вам перевірити файли на підрив, якщо вони не містять абсолютних шляхів та інших даних, які прив'язують їх безпосередньо до середовища одного розробника.

Якщо файли містять абсолютні шляхи тощо, README буде кращим вибором.

Так, неодмінно перевірте їх, але переконайтеся, що ви задокументували будь-які залежності шляху та уникайте абсолютних шляхів, якщо це можливо.

Якщо ви їх не зареєструєте, тоді кожному, хто перевіряє проект, потрібно буде відтворити всі ці налаштування, що дратує та потенційно спричиняє помилки.

Деякі складні налаштування можуть бути краще оброблені сценарієм для створення цих файлів, але зазвичай краще просто перевірити їх.