Является ли хорошей практикой включать файлы проекта Eclipse в исходные тексты в SCM?

Ответ на высшем уровне: это вопрос вкуса :-)

Лично для «внутренних» проектов (у вас есть некоторый контроль над средами других разработчиков) я действительно включаю файлы Eclipse с оговоркой, что вы должны быть уверены, что все используют относительные пути в своих конфигурациях. . (Каждые несколько месяцев у нас происходил перерыв в сборке, потому что путь к библиотеке был жестко закодирован. На исправление уходили секунды, но это раздражало.) Я также обычно много использовал такие вещи, как форматирование кода Eclipse и предупреждения компилятора настройки, чтобы облегчить жизнь (например, никаких огромных проверок Subversion, потому что чьи-то редакторы поссорились из-за вкладок форматирования).

В качестве бонуса, когда вы привлекаете нового разработчика, система проверки Eclipse Subversion автоматически настраивает проект, когда обнаруживает файлы .project в вашем стволе / ветке. Это двойная победа, если вы используете Eclipse для управления своей сборкой (в отличие, скажем, от Ant или Make).

Если вы работаете в более разнообразной команде (например: не однородно (так?) При использовании Eclipse), на практике они не доставляют особых неудобств. У меня есть один «совместный» проект, над которым я работаю, в котором есть папка, полная управляющих файлов MicroSoft Visual Studio и файл .project, и они должны синхронизироваться по отдельности, но, по крайней мере, есть «только два» набора. этих файлов для синхронизации. Без них в Subversion был бы один разработчик…

Я также слышал об использовании «фиктивного проекта» для хранения файлов проекта. например

svn://someplace.nn/projects/MyProject/trunk —> source
svn://someplace.nn/projects/MyProject.control/trunk —> project control files

Единственное место, которое я видел, было в проекте с большой веткой GPL и небольшим репозиторием локальных проприетарных надстроек, отличных от GPL ... ветка GPL не имела файлов .project, как большинство соавторов Сети не использовали Eclipse, файлы проекта находились на внутреннем (частном) сервере Subversion, а третий проект содержал собственный код плагина. (И четвертый для искусства, пятый для музыки…)

Я лично не рекомендую включать файлы конфигурации вашего проекта в SCM. Файл .project содержит относительный или абсолютный путь или URI, который может варьироваться от пользователя к пользователю. Спецификации для файла .project можно найти на здесь.

Практически все (рабочие) проекты, с которыми я сталкивался, хранят файлы .project в SCM. В основном по той причине, что в файле хранятся компоновщики и т. Д. Таким образом, у всех разработчиков есть единообразная конфигурация Eclipse.

Представьте себе сценарий, в котором вы все используете Checkstyle, кроме одного разработчика, который настаивает на том, чтобы вкладки в свои файлы :-).

Это относится не только к .project, но и .classpath, .checkstyle, ко всему в .settings.

Единственное, о чем вы должны быть осторожны, это то, что все, на что вы ссылаетесь в своих проектах, имеет путь относительно проекта, например, ваша конфигурация checkstyle. Это означает, что все, что вы используете, вероятно, также будет в SCM. Но это преимущество, потому что все это часть вашего процесса, верно?

Вышесказанное не обязательно относится к проектам FOSS из-за разнообразия используемых IDE.

вы можете подумать о добавлении плагина maven-eclipse в свой pom. таким образом, разработчик может проверить исходные коды и локально построить свой проект eclipse и импортировать его в рабочую область.

также, если у вас есть общие файлы конфигурации, связанные с eclipse (или плагином eclipse), вы также можете определить их в maven-eclipse-plugin. например checkstyle.xml, codeTemplate.xml, codeFormatter.xml .... сохранить эти файлы в scm может быть хорошей идеей.