it-swarm.com.ru

.classpath и .project - проверять контроль версий или нет?

Я запускаю проект с открытым исходным кодом Java, который состоит из нескольких модулей в дереве зависимостей. Все эти модули являются подкаталогами в хранилище Subversion. Для новичков в нашем проекте очень много работы по настройке всего этого вручную в Eclipse.

Не все наши разработчики используют Eclipse. Тем не менее, мы рассматриваем просто включить файлы .classpath и .project, чтобы помочь новичкам начать. Это хорошая идея? Или это приведет к постоянным конфликтам в этих файлах? Есть ли альтернативный способ облегчить настройку проекта на затмении?

84
amarillion

Определенно, да, как я уже сказал в " Поддерживаете ли вы файлы проекта под контролем версий? "

"Загрузите, настройте, иди".

Но ... это на самом деле верно только для последних настроек Eclipse3.5, где пути сборки поддерживают относительные пути :

Build path supports relative paths


И Eclipse3.6 будет лучше, так как он поддерживает относительные пути для переменных пути в Linked Resources:

path variable with relative path
(с версии 3.6M5)

63
VonC

Определенно нет - это вообще ужасная идея распространять файлы проекта через Subversion. Тем более, что кто-то может изменить их каким-то странным образом. Хорошая страница в документации проекта - гораздо лучшая идея. В нашем проекте также много модулей и сложной настройки. Мы создали страницу слияния, описывающую, как начать работу с проектом для каждого популера IDE - IntelliJ, Eclipse, NetBeans. Файл README в Subversion содержит ту же информацию.

17
Bozhidar Batsov

Я голосую "нет", но это потому, что я обычно генерирую эти файлы из maven

9
Goibniu

Я бы порекомендовал вам проверять файлы в Subversion, ЕСЛИ они не содержат абсолютных путей и других данных, которые бы связывали их напрямую со средой одного разработчика.

Если файлы содержат абсолютные пути и т. П., То README будет лучшим выбором.

5
vkraemer

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

    <classpathentry kind="con" 
      path="org.Eclipse.jdt.launching.JRE_CONTAINER/org.Eclipse.jdt.internal.launching.macosx.MacOSXType/Java SE 7"/>

Так что на моем Mac это работает, и, возможно, у кого-то на Mac есть такой же JRE, но это не будет работать ни для кого другого.

Кроме того, нет простого способа обойти это. Eclipse всегда будет добавлять это в. Я ХОЧУ иметь там файл .classpath, потому что в нашей папке lib есть некоторые сторонние JAR-файлы, где мы заботимся о версиях, поэтому мы оставляем их там, чтобы новые разработчики не получали их , Мы переходим к управляемой системе, но по-прежнему проверены управляемые + неуправляемые зависимости. Это означает, что все разработчики должны просто убедиться, что в их .classpath есть две директории. Но это лучше, чем исправлять свой JRE каждый раз, когда вы извлекаете, и вносить изменения в .classpath каждый раз, когда вы фиксируете.

Затмение делает некоторые другие хорошие вещи для вас, хотя. Файл .project обычно одинаков для разных экземпляров, поэтому включите его. Но самое лучшее в управлении исходным кодом для Eclipse - это настройки Run Configurations. На вкладке "Общие" в диалоговом окне "Выполнить конфигурации" сохраните конфигурации, чтобы они отображались для ваших коллег в списках избранного для "Отладка и запуск". Для меня куча файлов .launch находится в каталоге .settings, поэтому мы все можем их использовать.

Поэтому я говорю: каталог .settings входит в систему контроля версий для конфигураций запуска (кроме * .prefs)

.classpath остается вне

.project входит.

5
Zak Patterson

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

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

5
Arne Deutsch

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

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

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

2
Christopher Barber