Синхронизация зависимостей проекта Eclipse с внешней системой сборки

Question

Вот ситуация.Команда разработчиков имеет большое количество (сотни) проектов Eclipse.Код очень много: новые проекты создаются;проекты переименовываются, а зависимости проектов постоянно меняются.Внешняя система сборки - муравей.Чрезвычайно сложно поддерживать синхронизацию, определенную в файлах сборки ant, с состоянием мира в Eclipse.Внешний муравейник нуждается в постоянных изменениях, чтобы не отставать.По разным причинам использование ant в качестве компоновщика по умолчанию в Eclipse не вариант.Разработчики хотят продолжать использовать Eclipse в качестве среды сборки и редактирования для локального использования.

Вопрос: Существует ли инструмент, который позволит поддерживать один набор зависимостей, который может использоваться Eclipse, а такжевнешняя система сборки как муравей?Я слышал о Gradle, но никогда не использовал его раньше.Будет ли это иметь смысл в этом контексте?Я почти уверен, что Maven не будет работать для того, что нужно. Типичный рабочий процесс должен быть следующим:
1. Разработчики продолжают работать так, как они работают в настоящее время - по желанию создают и изменяют зависимости проекта Eclipse и используют компоновщик Eclipse по умолчанию для компиляции и тестирования локально.
2. Существует некоторый механизм, с помощью которого эти зависимости можно переносить во внешнюю систему сборки, такую ​​как ant, и внешнюю непрерывную сборку, запускаемую при каждой регистрации.
Благодарим вас за отзыв - спасибо!

Answer 1

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

• Каждый проект содержит build.gradle, который определяет специфичные для проекта зависимости и задачи (может даже быть пустым).
• Специальный master проект содержит build.gradle, который устанавливает общие зависимости и задачи для дочерних проектов и / или внедряет параметры, относящиеся к группе дочерних проектов.
  • Логически master проект - это проект parent , но он существует как одноуровневая папка, так что Eclipse может быть более удобным с ним.
• Gradle содержит встроенный плагин Eclipse, который позволяет генерировать файлы настроек Eclipse для каждого из проектов на основе информации о зависимостях (включая межпроектные зависимости).Он хорошо работает для простых проектов, а для более сложных Gradle позволяет вам возиться с файлами настроек, так что вы можете делать практически все.Отсюда у вас есть две опции:
  • Не сохранять файл настроек Eclipse в репозитории и вызывать задачу генерации каждый раз, когда вы делаете новую проверку (я предпочитаю эту опцию).
  • СкажитеGradle для использования пользовательских переменных, чтобы он генерировал общие файлы настроек, которые могут быть возвращены в хранилище.Тогда вам нужно будет только запустить задачу генерации, когда зависимости или другие изменения конфигурации.
• (Необязательно) Это немного сложно, но вы можете заставить Gradle анализировать существующие файлы проекта ivy.xmlи установить зависимости оттуда.У меня был некоторый успех в этом, хотя я бы порекомендовал преобразовать зависимости в формат Gradle для большей гибкости.
• Система непрерывной сборки очень хорошо интегрируется с Gradle (аналогично ant).Если вы используете Jenkins (Hudson), есть плагин Gradle.

Преимущество использования Gradle заключается в том, что он масштабируется довольно хорошо, и вы можете одновременно поддерживать другие IDE, такие как IntelliJ или Netbeans, безмного усилий (если у вас нет много сумасшедших пользовательских настроек).Преимущество и недостаток в том, что Gradle - это мощная система сборки, которая требует изучения Groovy и Gradle DSL, на приобретение которых может потребоваться некоторое время.Также документация великолепна.

У Gradle очень активное сообщество с единственной целью - решить именно эту проблему.

Надеюсь, это поможет, и удачи!

Answer 2

Как насчет парсинга файлов .classpath, создания дерева зависимостей и начала сборки из корня.Что вам нужно, так это соглашение о компоновке ваших проектов или общий (ant-) файл сборки, который можно изменить в каждом проекте, если это необходимо (например, различные макеты проекта).Я не уверен, что Eclipse Tycho может быть использован для этого, так как это плагин (ы) maven для создания плагинов или проектов Eclipse.Но он способен разрешать зависимости пакета и проекта от репозиториев maven и сайтов обновлений Eclipse.