переключение на Gradle с Maven для управления большим проектом ОСГИ (> 200 пакетов) - PullRequest
14 голосов
/ 04 июня 2011

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

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

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

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

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

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

[редактировать] В каждой связке есть раздел, подобный этому: `

         <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 Ответ

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

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

...