Использование Eclipse с большими рабочими пространствами - PullRequest
Новая
       10

Использование Eclipse с большими рабочими пространствами

4 голосов
/ 16 мая 2009

Наш текущий продукт основан на Eclipse RCP. У нас начинаются проблемы, когда мы пытаемся поместить всю нашу базу кода в одно рабочее пространство затмения, и нам было интересно, что делают другие.

Вот наша установка:

  1. ~ 225 проектов затмения (все в стволе / проекте)
  2. ~ 30 функций затмения (все в магистрали / функции)
  3. ~ 900 тыс. Строк кода

Мы находим несколько различных узких мест:

  1. SVN в Windows ужасно медленный (пробовал TortoiseSVN, SmartSVN, командная строка svn), обновление может занимать до 5-8 минут и обновляет только 10 маленьких файлов. Единственный разумный клиент - это subclipse / subversive, однако у них есть другие проблемы, и у нас были некоторые проблемы с ними.
  2. Обновление Eclipse может занять 3-5 минут
  3. Сборка Eclipse может занять 5-15 минут

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

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

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

Кто-нибудь еще сталкивался с этой проблемой? Если так, что ты делаешь, чтобы обойти это?

Спасибо.

1 Ответ

2 голосов
/ 16 мая 2009

Политика, принятая нами для такого рода конфигурации, основана на понятии развертывание .

Любой проект отвечает за сборку, а затем versionning его набор файлов для доставки (jar, war, ear, ...).

Это значит:

  • Любая «группа по интеграции», отвечающая за тестирование всей системы, может быстро обновить все поставки одним запросом к VCS без необходимости перестраивать их все. Отсюда и слово «развертывание»: этому способствует этот подход.

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

Таким образом, для любого данного проекта в eclipse фактически открывается только один, и он ссылается на различные библиотеки, поступающие из других проектов.

Это также заставило нас:

  • переосмыслить наши различные зависимости между всеми проектами (обнаружение некоторого случая удаления циклических зависимостей),
  • перепроверьте нашу аппликативную архитектуру, когда мы поняли, что несколько проектов были слишком "мелкозернистыми" и их необходимо было объединить вместе.

Есть два основных подхода:

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

При подходе к плагину eclipse необходимо найти золотую середину:
Все проекты из одного домена (например, "com.mycorp.fileutil[.XXX]") могут быть представлены проектами затмения с исходными зависимостями между ними. Но любой другой компонент, необходимый для "com.mycorp.fileutil", который не является частью этого домена, должен быть импортирован как библиотека, а не как исходная зависимость. Отсюда наша перспектива, ориентированная на развертывание, релиз первый.

...