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

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

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

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

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

3. для выполнения пакета и развертывания конечного артефакта нам нужен еще один подмодуль, который импортирует все пакеты, необходимые для развертывания (все, кроме нескольких для тестов и mocks). [отредактированный] Обратите внимание, что эта агрегация отличается от основной pom, поскольку она не компилирует пакеты, а просто выбирает их из репозитория 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, bundles и multi-modules

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

1 ответов


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

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