Почему люди gitignore .classpath и .project?

Question

Один из моих коллег недавно создал новый проект в Eclipse, совершенный и отправленный с помощью встроенного git клиента. После того, как я клонировал свой компьютер и открыл с помощью eclipse, я обнаружил, что eclipse создает файл .classpath. Разве .classpath не является решающим файлом для проекта eclipse (также .project) для поиска ссылочных jar-файлов? Я очень смущен после поиска в Google, видя, что все дискуссии говорят об их игнорировании. Разве они не важны для Eclipse, чтобы работать правильно? Почему люди игнорируют их? В чем проблема, если я их не проигнорировал?

Answer 1

Эти Специфичные для Eclipse c файлы облегчают настройку Eclipse и кода Visual Studio для проекта Java.

В общем, IDE и спецификации инструмента c файлы (Eclipse, Jenkinsfile, настройки рабочих процессов GitHub и т. Д. c.) Должны быть общими , если они используются и поддерживаются . В противном случае удалите их.

Конечно, если вы используете другую IDE , отличную от Eclipse и Код Visual Studio , и не используете компилятор Eclipse в IntelliJ IDEA , эти Eclipse-специфицированные c файлы бесполезны, но не наносят вреда . Пока вы не используете такие функции, как ссылки на файлы или папки (хранящиеся в файле .project), совместное использование этих файлов не приводит к блокировке IDE .

В Maven и В проектах Gradle файл .classpath может быть получен из файла pom.xml или build.gradle, но настройки , которые не могут быть получены , такие как настройки компилятора (предупреждения и ошибки), настройки форматирования или сохранения действий (которые являются хранится в папке .settings проекта) должен быть общим , чтобы все использовали одно и то же.

Это также относится к файлу .project, так как он содержит Какую природу имеет проект и какие инструменты требуются. Если чего-то не хватает, появится диалоговое окно с вопросом, следует ли установить отсутствующие плагины.

Eclipse помещает эти файлы в папку проекта, а не в папку .metadata, поскольку они предназначены для общего доступа. Но почему есть люди, которые не делятся этими файлами? Вероятно, из-за исторических причин . 15 или 20 лет go, не было Git, Мэйвен и Дженкинс. В наши дни приложение Java обычно создавалось на компьютере разработчика путем ручного экспорта JAR-файлов или, в лучшем случае, с помощью некоторых пакетных сценариев / сценариев оболочки. Это означало, что одна и та же сборка на другом компьютере или даже просто с другой версией IDE или IDE может привести к другому результату, что вызовет массу проблем. IDE agnosti c builds было решением этой проблемы. Может быть, поэтому люди сегодня все еще думают, что все должно быть IDE agnosti c и рекомендуют использовать Maven или Gradle. Но эти файлы не доступны для сборки продукта, который будет поставляться. Будем надеяться.

Answer 2

Это очень сильно зависит.

Если , ваша команда решит, что файлы конфигурации проекта eclipse являются важным источником правды, и все остальные должны их использовать: тогда, конечно, эти файлы должен сидеть в вашем хранилище управления исходным кодом.

Но это приводит к блокировке IDE. Или, что еще хуже, это приводит к тому, что несколько файлов содержат одинаковую информацию, поскольку будущий пользователь IntelliJ может предпочесть добавить файлы .iml поверх этого. Поэтому любое изменение в определениях проекта должно произойти дважды сейчас.

Итак, в идеале, в 2020 году: используйте другие инструменты в качестве базового источника истины (например, определения gradle) ), а затем скажите вашей индивидуальной среде IDE использовать это.

Answer 3

Это спецификация Eclipse c, поэтому они не относятся к исходному коду проекта. Разработчики могут использовать разные IDE, поэтому Eclipse .classpath будет бесполезен, например, для тех, кто использует IntelliJ IDEA.

Поскольку проект, скорее всего, использует Maven / Gradle / некоторую другую систему сборки, IDE способна генерировать как вы заметили, classpath основан на файлах pom.xml или build.gradle. Только если нет системы сборки и проект IDE указывает c, необходимо будет включить эти файлы, чтобы убедиться, что проект хранит свои метаданные. Но это маловероятный сценарий в наше время и в реальных рабочих ситуациях.

Обычно это не вызывает проблем при их включении (если не существует конфликтующих спецификаций проекта c конфигурации от разных разработчиков), но они тоже не обязательно. Я не включаю их, потому что нет никакого преимущества, и это сохраняет root проекта чище.