Переключение на gradle из maven для управления большим проектом osgi (> 200 пакетов)

У нас есть большой проект (~ 215 пакетов и подсчет) osgi (felix + springdm), построенный с помощью maven и плагина maven-osgi.

У нас есть несколько проблем с maven:

1. subodules pom должны унаследовать от родительского pom, чтобы воспользоваться общими переменными и зависимостями (это нормально), но тогда родительский pom должен включать все пакеты pom, чтобы иметь возможность строить все вместе. Этот вид циркулярной ссылки делает очень сложным синхронизацию.

2. индивидуальная версия подрасслоений была настолько сложной, что было принято решение (до того, как я присоединился к проекту) использовать одну и ту же версию для всех пакетов. Это означает, что теперь мы обновляем версию всех пакетов для каждой версии, даже если на самом деле их просто изменяет. Это делает всю концепцию osgi немного бессмысленной ИМХО. Обратите внимание, что я не говорю, что мы продолжаем затрагивать только меньшинство пакетов, мы работаем над всеми из них, но каждый выпуск обычно содержит 1 или 2 функции, которые затрагивают только некоторые пакеты.

3. для выполнения пакета и развертывания финального артефакта нам нужен еще один подмодуль, который импортирует все пакеты, необходимые для развертывания (все, кроме нескольких для тестов и макетов). [Редактировать] Обратите внимание, что эта агрегация отличается от той, что находится в основном помпе, поскольку она не компилирует пакеты, а просто выбирает их из репозитория maven.

4. система зависимостей maven и импорт плагинов osgi иногда трудно поддерживать. Слишком просто забыть об импорте или поставить неправильную зависимость.

[редактировать] В каждом пакете pom есть такой раздел: `

         <plugin>
            <groupId>org.apache.felix</groupId>
            <artifactId>maven-bundle-plugin</artifactId>
            <extensions>true</extensions>
            <configuration>
                <instructions>
                    <Export-Package>
                    </Export-Package>
                    <Import-Package>
                        com.google.gson,
                        org.apache.log4j,
                        org.apache.log4j.spi,
                        org.dom4j,
                        com.myinterfaces
                    </Import-Package>
                </instructions>
            </configuration>
        </plugin>`

По всем этим причинам мы в порядке, но не совсем довольны maven. Недавно кто-то предложил Gradle не как панацею, а как определенные улучшения в текущей ситуации.

Не могли бы вы переехать в gradle? и в случае, если это будет наилучшим образом?

Кто-то другой испытал такую же ситуацию? Я думаю, что это должно быть общим для всех крупных проектов с Osgi.

Отказ от ответственности: я искал похожие вопросы:

Buildr, Gradle или ждать Maven 3?

Ищите хорошую среду разработки для пакетов OSGi

Maven: OSGI, пакеты и проекты с несколькими модулями

но там, где не о субмодулях osgi или не о gradle.

Ответ 1

Вы можете разделить родительский и совокупный модули maven, поскольку в настоящее время ваш родительский pom имеет две роли, которые вы правильно наблюдали. Более подробную информацию можно найти в Maven Введение в POM.
Я боюсь, что управление версиями не может стать проще, если вы не используете API Tools. Возможно, было бы здорово, если бы инструменты API могли быть интегрированы как плагин Maven, но я не знаю никакой работы в этой области. Таким образом, вы либо трогаете все версии сразу, либо обновляете их каждый раз, когда это необходимо. Инструменты API очень помогут здесь, но они работают только для пакетов, которые могут быть импортированы в виде проектов Plug-in внутри Eclipse.
Итак, поможет ли еще один модуль агрегатора? Вы можете настроить несколько агрегаторов, которые объединяют другие агрегаторы, так что вы не получите один огромный модуль агрегатора, который перечисляет все? Поскольку вы можете не захотеть развертывать все, вы можете настроить исключение из развертывания. Быстрый поиск в Google показал, как сделать it.
@Neil Bartlett уже отметил, что bnd позаботится о вашем манифесте, если вы правильно настроили свои зависимости. Если вам нужна дополнительная настройка по умолчанию, вы всегда можете установить файл инструкций BND.

Вы можете поместить Tycho в список возможных инструментов. Это поможет вам в управлении зависимостями, потому что вам нужно указывать свои зависимости только в манифесте, и это позволит вам использовать инструменты API (но пока не интегрировать). Однако вам потребуется использовать репозитории p2, если вы хотите пропустить некоторые головные боли (пока Tycho не улучшит их поддержку в зависимости от артефактов Maven).