Полезно ли включать файлы проекта Eclipse в источники в SCM? - PullRequest
6 голосов
/ 07 декабря 2011

У нас довольно сложный многомодульный проект Maven. Существуют модули Flex, модули GWT, модули Java и несколько модулей WAR. Чтобы упростить процесс импорта этих проектов в Eclipse, исторически мы включили все соответствующие файлы проектов Eclipse в дерево исходных текстов.

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

Как правило, проекты включают эти файлы Eclipse в Subversion / Git / etc?

Ответы [ 4 ]

3 голосов
/ 07 декабря 2011

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

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

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

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

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

3 голосов
/ 07 декабря 2011

Ответ высшего уровня: это дело вкуса: -)

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

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

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

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

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

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

3 голосов
/ 07 декабря 2011

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

2 голосов
/ 07 декабря 2011

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

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

...