Проект Java: должен ли файл .classpath.project быть включен в репозиторий?

Должен ли я проверить мои файлы .project и .classpath?

Мой друг сказал мне, что я должен только проверять файлы .java и build.xml, чтобы гарантировать переносимость. Он сказал: ".classpath приведет к значительно меньшей переносимости в разных средах..project - это полностью локальная настройка затмения"

Я согласен с ним, но частично.

- Не проверять файл .project сделает мою разработку менее эффективной (я не могу просто "импортировать" код проекта из каталога)

- Не проверять файл .classpath, кажется мне хорошо (?), если мой файл build.xml написан тщательно.

Кто-нибудь хочет поделиться своим опытом здесь?

Ответ 1

Нет ничего плохого в проверке в .project и .classpath. Я сделал бы это, если ваш build.xml не сможет создать оба файла для вас. Как вы сказали, неудобно пропустить эти файлы при попытке создать новое рабочее пространство eclipse.

Перед тем, как зарегистрироваться .classpath, вы должны быть уверены, что в нем нет абсолютного пути. Преобразуйте его в относительный с текстовым редактором.

Изменить: Или, что еще лучше, используйте переменные класса eclipse в своих абсолютных точках, например, @taylor-leese.

Ответ 2

Одна вещь, на которую я бы посоветовал проверить файл .classpath, - это убедиться, что вы не ссылаетесь на файлы вне вашего проекта. Eclipse хранит расположение этих файлов с полным пути к файлу, и вам нужно будет убедиться, что другие разработчики имеют эти файлы точно в одном месте.

Ответ 3

Ключевой вопрос во всех таких файлах: "Могут ли они быть воспроизведены автоматически?" Если нет, проверьте их в исходном элементе управления.

В этом случае я бы сказал "да", если вы не используете maven, у которого есть m2eclipse и плагин eclipse, чтобы сгенерировать их для вас.

Ответ 4

Я не знаю файлы предпочтений eclipse, но с IntelliJ эти файлы являются агностиками ОС, а это значит, что это не испортит вашу мобильность. Если вы не определяете библиотеки с полным путем к вашей системе (это было бы довольно опасно/глупо).

Когда вы делитесь предпочтениями, вы уверены, что все будут работать с теми же условиями в проекте (настройка плагинов, кодирование, профили [для intelliJ]), что действительно может быть хорошим.

Это не беспокоит меня, когда некоторые файлы Eclipse здесь, и я думаю, что это не должно/не беспокоит других разработчиков, когда некоторые скрытые файлы просто лежат там.

Ответ 5

Мы проверяем .project и .classpath. С помощью ProjectSet это позволяет нам проверять сложные рабочие области с помощью одного "Import Team ProjectSet"

Ответ 6

За мои 2 цента я бы оценил это как плохую практику. Проекты не должны привязываться к среде IDE и особенно не должны привязываться к определенной версии среды разработки.

Проверка конфигурационных файлов Eclipse может работать хорошо для более простых и краткосрочных проектов. Для более крупных проектов, которые разрабатываются в течение нескольких лет, это, как правило, вызывает больше хлопот, поскольку версии IDE меняются, а файлы конфигурации проекта - нет. Представьте себе, что вы проверили 2-летнюю ветку с конфигурационными файлами Eclipse 2.0 в Eclipse 4.3 с некоторыми настраиваемыми библиотеками и интеграцией m2e... Не весело вообще...

Ответ 7

Не проверять файл .project. сделайте мое развитие менее эффективным (I не может просто "импортировать" код проекта из каталога)

для этой проблемы вы можете создать новый проект и импортировать существующий источник.

одна проблема с определенными файлами IDE, такими как .project, заключается в том, что другие разработчики могут захотеть использовать другую IDE, чтобы развить проект, чтобы они могли добавлять файлы проектов другого типа. это сделает ваш репо грязным.

Ответ 8

Я бы предпочел проверить .project и .classpath.

Это было бы полезно, если этот проект будет разделен несколькими разработчиками. Легко и быстро становится для настройки разработки., просто импортируя это как существующий проект на любой с помощью eclipse.

Здесь необходимо соблюдать осторожность, так как путь к классам относится к проекту.

Ответ 9

У меня часто есть аналогичные, более общие вопросы. Проблема в основном такова:

какие файлы я собираюсь для меня?
какие файлы я совершаю для других?
→ Как объединить обе цели "версии"?

Я предложил обсудить этот там, чтобы вы могли найти более подробную информацию о проблеме вместе с интересными решениями:)

То, что мне больше всего нравится, - это использование git submodule: сохранить ваши файлы .project и т.д. в частном делете репо. И сделайте свое окончательное, чистое, существенное src производство в аккуратный самородок submodule: публичное репо.

project/ # root module
|   .git # private repo
|   .project
|   .classpath
|   momsNumber.txt
+---src/     # submodule
|   |   .git # public repo
|   |   main.java
|   +---package/
|   |   |    Etc.java

См. там в любом случае.

Ответ 10

Нет проблем с проверкой файлов .classpath и .project в репозитории. Это поможет разработчикам, которые используют Eclipse для ускорения работы.

Предупреждение. Убедитесь, что ваш файл .classpath ссылается только на артефакты, которые либо проверяются в репозитории с проектом, либо могут быть получены автоматически (например, артефакты maven).