2
votes

I recently migrated my NetBeans Platform (NBP) based application from Ant to Maven. I pretty much figured Maven out but there's one thing I still cannot get my head around, and that is the version system/convention.

It seems that everyone in the Maven world with a large Maven project consisting of multiple modules uses a parent pom in which they define a version, which is then inherited by all child pom's (i.e. all NBP Modules in Maven NetBeans RCP project).

For instance, take a look at the final result of the example project in the maven book: http://books.sonatype.com/mvnex-book/reference/optimizing-sect-final-poms.html

You will see one version defined by the parent POM,

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

which is inherited by each child module, by specifying the parent and not using any tag of its own:

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

and for its internal (within the project) dependencies each child module defines this relative to the project:

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

This means that you cannot update one module to a higher version because it will then look for dependencies with the same version number, which don't exist. Not to mention that using a separate version for any of your child modules gives you headaches when using the versions-maven-plugin because you end up micromanaging your dependencies.

This seems to completely go against the AutoUpdate / Lifecycle / Release philosophy of the NetBeans Platform. There I could update one module and generate a new updates.xml ("Package as NBMs") and when uploaded to an AutoUpdate repository, a client will see just that one update. It seems that if you do it the Maven way (mvn nbm:autoupdate), all modules get a version bump so that the whole model of auto updating via modules goes down the drain.

I hope I am mistaken and there is somewhere a feature to restore the great autoupdate functionality that comes with the platform, some kind of extra version number that automatically gets added to the major.minor.revision number or some intelligent way to override OpenIDE-Module-Specification-Version = major.minor.revision in between releases versions. Is there or do I have to release a new version of my application for each tiny update to a client module?

1

1 Answers

0
votes

There is no silver bullet.

Keeping the version in one place makes sense when you are releasing the entire thing together eg. when your thing is a webapp. Then it's simpler to just keep the version intact as you are building and deploying stuff together. With Netbeans platform you should think in the same terms. If something is part of your base application you ship, make it the same version for the base app releases and only diverse for patches shipping to customers later on. That's more or less the model netbeans itself has adopted (in ant based codebase though but all modules get a version bump after a major release)

If a plugin or set of plugins is optional or works in multiple versions of the base app or works with multiple different applications put them in a separate repository with their own versioning.

Making a release of single module within a git repository for example (using maven:release) could bring problems of it's own. Eg. when maintaining multiple different branches (patches for older versions etc) Play with the combination for a bit to see which things suit your workflow and release cycle.

Please note that the final assembly of the application is done in the nbm-application project and not the maven reactor. Maybe the easiest way to manage the dependencies would be to keep the nbm-application final assembly separate (separate maven build, separate git repository).

Keeping each netbeans module in it's own repository allows you to micromanage the versioning but you still need to update the module's pom during release but also as the nbm-application dependency to include the new version in auto update or application. Thus you can separate a plugin release from plugin deployment to customers which can be a good thing. These multiple steps can be automated in your CI server but do add complexity to your builds.

So your mileage may vary based on how your application gets distributed, how tight are your inter-module dependencies etc.