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

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

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

ОТВЕТЫ

Ответ 1

Окончательно да, как я сказал в Сохраняете ли вы файлы проекта под контролем версий?

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

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

Build path supports relative paths

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

path variable with relative path
(начиная с 3.6M5)

Ответ 2

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

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

По моему опыту, исключая ограниченные случаи, когда речь идет о чисто локальных настройках, все должно быть в контроле источника. Закон управления источниками заключается в том, что все, что нужно сделать, должно работать теми, кто вытаскивает. К сожалению, затмение часто вызывает такие вещи как .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 s. Но это лучше, чем исправлять вашу JRE каждый раз, когда вы тянете и меняете свой .classpath каждый раз, когда вы совершаете.

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

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

.classpath остается

.project входит.

Ответ 7

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

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

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