2015-02-14 5 views
1

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

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

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

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

<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> 

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

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

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

ответ

0

Нет серебряной пули.

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

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

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

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

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

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