Чтобы проверить или не проверить весь проект Eclipse?

Question

Я скоро собираюсь проверить самый первый коммит нового проекта Java. Я работаю с Eclipse Ganymede и несколько плагинов делают вещи немного проще.

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

• Я сильно подозреваю, что некоторые файлы конфигурации Eclipse будут меняться без взаимодействия с пользователем (с тех пор, как я использовал Eclipse Europa), поэтому они будут выглядеть как измененные (как они были изменены, но не в интерактивном режиме), когда пришло время сделать коммит.
• Существуют настройки, уникальные для каждой машины разработки, а также глобальные настройки для всех разработчиков проекта. Держать их отдельно было трудно.
• Иногда, если версия Eclipse отличается от других, Eclipse разозлится и испортит конфигурацию проекта. Другой случай - это то, что он изменяет формат, чтобы он обновлялся, и если зафиксировано, портит конфигурацию для других.

Для этого конкретного проекта у меня есть еще одна причина не фиксировать файлы проекта:

• Возможно, разработчики предпочитают NetBeans, который присоединится к проекту позже. Однако они не присоединятся в ближайшие месяцы.

Как вы это организовали? Что вы проверяете в управлении версиями и что вы держите на улице? Что вы считаете лучшей практикой в ​​такой ситуации?

Answer 1

Как минимум, вы должны проверить файлы .project и .classpath. Если кто-то в вашей команде жестко кодирует внешнее местоположение JAR в .classpath, вы должны положить их к стене и выстрелить в них. Я использую Maven для управления своими зависимостями, но если вы не используете maven, вам следует создать пользовательские библиотеки для внешних JAR-файлов с согласованным соглашением об именах.

После этого вам нужно учитывать все, что связано с плагином. Например, я работаю с Spring, поэтому я всегда регистрирую .springBeans и аналогично CheckStyle, я всегда регистрирую проект .checkstyle.

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

• .settings / org.eclipse.jdt.ui.prefs - содержит настройки для порядка импорта
• .settings / org.eclipse.jdt.core.prefs - содержит настройки для версии компилятора

В общем, я не заметил, как Ganymede модифицировал файлы, пока я не изменил настройки проекта.

Answer 2

Я рекомендую использовать maven , чтобы весь жизненный цикл находился вне какой-либо IDE. Вы можете легко создать проект eclipse с ним в командной строке и использовать все, что захотите, если это не затмение. У него есть свои причуды, но он избавляет от горечи, когда дело доходит до зависимостей и управления сборкой.

Answer 3

В нашем мире мы регистрируем весь проект Eclipse и весь параллельный, но отдельный проект Netbeans. Наши мотивы для этого были полностью сосредоточены на том, «когда я делаю заказ, я хочу функциональную конфигурацию сразу после». Это означает, что нам пришлось проделать определенную работу:

1. Создание запускаемых конфигураций для каждой основной IDE (людям нравится то, что им нравится). Это включает в себя основной класс, рабочий каталог, параметры виртуальной машины и т. Д.
2. Создание полезных сценариев запуска для всех наших соответствующих сценариев.
3. Создание отредактированных наборов данных, которые не приводят к тому, что оформление заказа занимает слишком много времени (это большой проект).

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

Продолжение : эта философия «сделать жизнь нового парня проще» снова окупилась, когда он сменил IDE (он решил попробовать Netbeans после использования Eclipse в течение довольно долгого времени и решил придерживаться его какое-то время). Конфигурация вообще не требовалась, он просто открыл проект Netbeans в том же каталоге, на который указывал Eclipse. Истекшее время переключения: приблизительно 60 секунд.

Answer 4

Я только проверяю, что все сделано людьми, все остальное, что генерируется (автоматически или нет), должно быть легко регенерироваться и может измениться (как вы заявили). Единственное исключение из этого - когда сгенерированные файлы трудны (требует большого вмешательства человека;)), чтобы понять это правильно. Как бы то ни было, такие вещи действительно должны быть автоматизированы.

Answer 5

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

Есть плагины только для всего. Как плагин Eclipse. Вы просто набираете «mvn eclipse: eclipse», и плагин генерирует весь ваш готовый к работе проект eclipse.

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

Answer 6

Мне нравится проверять .project, .classpath и подобные файлы , только если они все равно будут идентичны на любом компьютере пользователя Eclipse. (Люди, использующие другие IDE, должны иметь возможность проверить и построить ваш проект независимо от того, но эта проблема ортогональна тому, проверять или не проверять файлы только в Eclipse.)

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

Answer 7

Netbeans 6.5 имеет улучшенный импорт проекта Eclipse, который должен синхронизировать изменения из Netbeans обратно в Eclipse: http://wiki.netbeans.org/NewAndNoteWorthyNB65#section-NewAndNoteWorthyNB65-EclipseProjectImportAndSynchronization

Answer 8

В нашем случае мы использовали файлы проекта (.project и .classpath), чтобы всем разработчикам было легко создавать рабочее пространство проекта. Общий файл настроек и набор командных проектов также находились в управлении исходным кодом, поэтому создание рабочего пространства было таким же простым, как настройки импорта и набор командных проектов импорта. Это сработало очень хорошо, но все зависит от согласованной среды, любые настройки должны быть применены после создания основного рабочего пространства.

Мы по-прежнему делаем это по большей части, но сейчас используется Maven, поэтому, конечно, вместо этого управление зависимостями осуществляется через Maven. Чтобы избежать противоречивой информации, .project и .classpath были удалены из системы контроля версий и теперь генерируются с помощью maven целей перед тем, как мы импортируем набор командных проектов. Это легко позволило бы использовать различные среды, поскольку вам просто потребуются сценарии для генерации отдельных частей IDE на основе конфигурации Maven.

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

Answer 9

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

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

Answer 10

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

Я не проверяю файлы JAR. Я храню их в отдельном хранилище, а-ля Maven 2.

Я не проверяю в WAR-файлах, JAR-файлах, Javadocs или в других объектах, которые могут быть созданы.

Я проверяю SQL и скрипты, исходный код Java и XML config.