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

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

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

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

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

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

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

Ответ 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 меняет файлы без меня, изменяя настройки проекта.

Ответ 2

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

Ответ 3

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

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

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

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

Ответ 4

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

Ответ 5

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

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

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

Ответ 6

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

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

Ответ 7

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

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

Я не проверяю WARs или JAR или javadocs или что-то еще, что может быть сгенерировано.

Я проверяю SQL и скрипты, а также источник Java и конфигурацию XML.

Ответ 8

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

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

Ответ 9

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

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

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

Ответ 10

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

Ответ 11

не делать. Проверьте только исходный код ваших проектов.

Ответ 12

В ответ на:

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

Eclipse предлагает несколько способов управления локальными параметрами: переменные класса Java (путь к Java > путь сборки > переменные класса) - это один, "Связанные ресурсы" ( "Общие" > "Рабочее пространство" > "Связанные ресурсы" ) - это еще один http://help.eclipse.org/stable/index.jsp?topic=/org.eclipse.platform.doc.user/concepts/concepts-13.htm Создание README, в котором указано, какие настройки, которые должны быть установлены до создания/запуска проекта, работает на мой взгляд.

Теперь, как убедиться, что ваша система непрерывной сборки понимает изменения, внесенные в настройки eclipse, это еще одна проблема... (У меня есть отдельный файл build.xml для ant, который я постоянно обновляю вручную)