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

87

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

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

амариллион
источник
1
возможный дубликат Shoul Я держу файлы проекта под контролем версий?
Стив Чемберс,

Ответы:

65

Определенно да, как я сказал в разделе « Держите ли вы файлы проекта под контролем версий? »

«Загрузите его, настройте, вперед».

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

Путь сборки поддерживает относительные пути


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

переменная пути с относительным путем
(с версии 3.6M5)

VonC
источник
2
Вау, я не знал, что они добавили это ... Избавило бы нас от горя
Ури
Похоже, изображения, связанные с этим ответом, отключены.
vkraemer
1
@vkraemer: правда. Я восстановил эти два изображения, первое из которых взято из archive.eclipse.org/eclipse/downloads/drops/R-3.5-200906111540/…, а второе - из download.itemis.com/mirror/eclipse/R-3.6. -201006080911./… .
VonC
17

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

Божидар Бацов
источник
31
Я не могу согласиться. По моему опыту, хорошо проверять эти файлы, чтобы упростить оформление заказа. Кто-то может их как-то странно изменить? Кто-то может каким-то странным образом изменить ваш код ...
Арне Дойч,
Арне, ты должен дать ответ, а не комментарий.
amarillion
5
Файлы проекта для любой IDE на самом деле не являются частью какого-либо проекта - если вы хотите их распространять - идите - прикрепите их к статье, которую я упомянул. Как правило, каждый в команде может изменять файлы в репозитории, но не каждый может прикреплять новые файлы к важным узлам документации и т. Д. Кто-то очень легко может забыть игнорировать путь к классам и файлы проекта и зафиксировать их, когда этого не следует делать. Даже если вы держите их на подрывной деятельности - вы обязательно должны держать их где-нибудь в стороне ...
Божидар Бацов
8
-1, больше не могу не согласиться. Настройки проектов являются важной частью повседневной работы над проектом. Недостатков случайной проверки неправильных настроек намного меньше, чем преимуществ автоматического поддержания всех в курсе событий. Ведь всегда можно легко вернуться к предыдущим версиям.
Майкл Боргвардт
7
Каждый имеет право на свое мнение. Собственно говоря, я бы никогда не создавал проект, полагающийся в первую очередь на систему проектов Eclipse (или любую другую IDE) ... Maven - это идеальный инструмент для понимания проекта, который делает определенные настройки IDE устаревшими. Между прочим, время заметить, что с текущими настройками что-то не так, и вернуться к предыдущей версии вряд ли будет отличаться от времени, чтобы самостоятельно настроить какие-либо новые настройки. По крайней мере, в моей компании каждый член команды получает уведомление по электронной почте, если после крупных изменений требуется вмешательство пользователя.
Божидар Бацов
10

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

Гойбню
источник
m2e делает для вас больше всего, но не все,
Цзюньчэнь Лю
6

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

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

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

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

.project идет в.

Зак Паттерсон
источник
Так ли это даже при использовании среды выполнения для JRE / JVM?
Mr_and_Mrs_D
5

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

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

Арне Дойч
источник
5

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

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

vkraemer
источник
2

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

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

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

Кристофер Барбер
источник