Есть.settings/org.eclipse.jdt.core.prefs часть проекта?

Ответ 1

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

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

Примечание. Для этого также требуется, чтобы вы фактически настроили все связанные с Java настройки в свойствах проекта. Никогда не используйте настройки компилятора Java в разделе "Окно → Настройки", если вы хотите иметь автономные проекты.

Чтобы дать конкретный пример: если вы настроили уровень соответствия компилятора вашим проектам на Java 6, потому что вы используете специальные функции Java 6 (например, переопределить аннотации на интерфейсах), тогда проект создаст много ошибок компиляции на других компьютерах людей, Это связано с тем, что уровень совместимости компилятора по умолчанию в каждой рабочей области Eclipse - это Java 1.5, а в Java 1.5 запрет аннотации Override просто запрещен.

Это не имеет никакого отношения к тому, разрабатываете ли вы закрытый источник или открытый источник, как указано в другом ответе.

Ответ 2

Вопреки мнению @nitind, нет. Вы не должны указывать какие-либо специфичные для IDE настройки под контролем версий. Кроме того, вы разрабатываете возможности IDE или плагины.

Если у вас действительно есть обязательные настройки IDE для всей команды, то их отличная проверка будет хорошей идеей, но ИМО, обладающая обязательными настройками для всей команды, сама по себе не является хорошей идеей.

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

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

EDIT2: Боюсь, @Bananenweizen не понимает, что я пытаюсь сказать.

Я знаю, что эти параметры являются настройками компилятора eclipse. Они все еще специфичны для IDE в том смысле, что они не будут иметь никакого эффекта в Netbeans или IntelliJ, так как они не будут влиять на сборки ant или maven из командной строки.

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

Eclipse не создает проекты сам по себе - он строит их с муравьем, если это проект eclispe или ant, или с maven, если это проект maven. И ant, и maven имеют определенные настройки исходной версии, которые не зависят от IDE.

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

Ответ 3

Вот проблема с установкой его под контроль версии... Если вы импортируете и открываете проект, Eclipse настаивает, когда вызывается IProject.open(...) при касании файла в папке.settings... и это прежде чем вы сможете зарегистрировать поставщика команды на объекте IProject. Это означает, что validateEdit не будет срабатывать, и вы получите раздражающие ошибки, если вы нажмете "да" или "нет" на всплывающее окно с вопросом: "Вы хотите сделать его доступным для записи?" Это все хорошо и полезно для оптимистичных поставщиков блокировки файлов, но не так хорошо для "пессимистических". Для нас это просто еще одно раздражение затмения.

Если это зависит от меня, я бы не поставил их в исходное управление.

Ответ 4

Ответ "да", и здесь вы найдете мотивацию для этого и правильный способ сделать это: смотрите разговор "Согласование метаданных IDE: неправильные представления, недоразумения и решения". или посмотрите соответствующие слайды EclipseCon Europe 2015 от Aurélien Pupier @apupier (старший инженер-программист, специалист Eclipse).