Проблемы автоматического обновления с приложением платформы Mavenized NetBeans

Недавно я перенес свое приложение на основе платформы NetBeans (NBP) с Ant на Maven. Я в значительной степени понял Maven, но есть одна вещь, которую я до сих пор не могу понять, и это система/конвенция версий.

Кажется, что все в мире Maven с большим проектом Maven, состоящим из нескольких модулей, используют родительский pom, в котором они определяют версию, которая затем наследуется всеми дочерними pom (т. е. всеми модулями NBP в проекте Maven NetBeans RCP).

Например, взгляните на окончательный результат примера проекта в книге maven: http://books.sonatype.com/mvnex-book/reference/optimizing-sect-final-poms.html

Вы увидите одну версию, определенную родительским POM,

<groupId>org.sonatype.mavenbook.optimize</groupId>
<artifactId>simple-parent</artifactId>
<packaging>pom</packaging>
<version>1.0</version>

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

<parent>
    <groupId>org.sonatype.mavenbook.optimize</groupId>
    <artifactId>simple-parent</artifactId>
    <version>1.0</version>
</parent>

и для своих внутренних (в рамках проекта) зависимостей каждый дочерний модуль определяет это относительно проекта:

<dependency>
            <groupId>${project.groupId}</groupId>
            <artifactId>simple-weather</artifactId>
            <version>${project.version}</version>
</dependency>

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

Кажется, это полностью противоречит философии AutoUpdate/Lifecycle/Release платформы NetBeans. Там я мог обновить один модуль и сгенерировать новый файл update.xml («Пакет как NBM»), и при загрузке в репозиторий AutoUpdate клиент увидит только это обновление. Кажется, что если вы сделаете это способом Maven (mvn nbm:autoupdate), все модули получат повышение версии, так что вся модель автоматического обновления через модули пойдет насмарку.

Я надеюсь, что ошибаюсь, и где-то есть функция восстановления отличной функциональности автоматического обновления, которая поставляется с платформой, какой-то дополнительный номер версии, который автоматически добавляется к номеру major.minor.revision, или какой-то разумный способ переопределить OpenIDE-Module-Specification-Version = major.minor.revision между ними. выпускает версии. Должен ли я выпускать новую версию моего приложения для каждого крошечного обновления клиентского модуля?


java netbeans maven auto-update netbeans-platform
person jsnel    schedule 14.02.2015    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Серебряной пули не существует.

Хранение версии в одном месте имеет смысл, когда вы выпускаете все вместе, например. когда ваша вещь - веб-приложение. Тогда проще просто сохранить версию нетронутой, пока вы создаете и развертываете вещи вместе. С платформой Netbeans вы должны мыслить в том же ключе. Если что-то является частью вашего базового приложения, которое вы отправляете, сделайте его одной и той же версией для выпусков базового приложения и отличайтесь только для исправлений, отправляемых клиентам позже. Это более или менее модель, принятая самой netbeans (хотя в кодовой базе на основе муравьев, но все модули получают обновление версии после основного выпуска)

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

Например, выпуск отдельного модуля в репозитории git (с использованием maven:release) может вызвать собственные проблемы. Например. при поддержке нескольких разных веток (исправлений для более старых версий и т. д.) Немного поэкспериментируйте с комбинацией, чтобы увидеть, какие вещи подходят для вашего рабочего процесса и цикла выпуска.

Обратите внимание, что окончательная сборка приложения производится в проекте nbm-application, а не в реакторе maven. Возможно, самым простым способом управления зависимостями было бы отделить окончательную сборку nbm-приложения (отдельная сборка maven, отдельный репозиторий git).

Хранение каждого модуля netbeans в собственном репозитории позволяет вам микроуправлять версиями, но вам все равно нужно обновлять pom модуля во время выпуска, а также как зависимость nbm-application для включения новой версии в автоматическое обновление или приложение. Таким образом, вы можете отделить выпуск плагина от развертывания плагина для клиентов, что может быть хорошо. Эти несколько шагов можно автоматизировать на вашем CI-сервере, но они усложняют ваши сборки.

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

person mkleint    schedule 14.02.2015