Maven NetBeans Module Plugin

you seem to have a misconception of what the specification-version denotes. It's not a build number. the spec version is stripped, because that's the constraint of spec versions which have format x.y.z.

SNAPSHOTs in general are not for customer consumption, but development snapshots. I suppose you can force jnlp redownload by deleting local caches.

The same principle/problem applies to netbeans update center which will only serve a new version of a module when the spec version is increased. Even if a binary with newer content, it will only be updated if no or lower spec version is present at the client side. This can indeed cause a situation where multiple clients have different local code executed based on when the code was downloaded.
It's not entirely compatible with maven versioning where you shall have only a single released binary for a given version.

if you actually need a timestamped version of your modules (which i doubt is the case) then you can IMHO achieve the same by actually releasing a new version of the module(s) with each "official build".

I agree with you and with your explanation.

Now I will try, why we need timestaped versions. If we will be releasing application, we will increase the specification version and will not play with timestamps.

But in development, the nightly builds are deployed on webstart server and testers use webstart application for testing. When the versions will be fixed (specification-version), they will never get actual build of application - only in case, they will manually delete local cache. This will also cause download of all libraries, that have fixed version (without changes).

But if the versions of modules will be timestamped, there is no need to delete local cache, testers will download only new modules with changes, rest of libraries will remain same without downloading.

I agree, that it is not so standard solution, but in our case it is needed solution. It can be enabled on some switch and default behavior can remain the same like now.

just a suggestion, not sure how it would actually work and what the interaction with release-plugin would be, but..

1. let's have <version>1.2${buildnum}-SNAPSHOT</version> element in the relevant projects.
2. the default value of buildnum would be empty string - used for developer local machines and real releases.
3. a profile activated on the nightly build machine would inject buildnum value of ".0.<the actual_build number_in_correct_format>". Please note that the zero at the start allows you to have correct ordinality for 1.2.1-SNAPSHOT version if you decide to use it.

I suppose you can impose the buildnum modifier on regular projects only, not on any parents..

I will try this solution, thanks for idea.

Edit:

I tried this solution, looks like the working one, but doesn't.

If I specify version like <version>1.2${buildNumber}-SNAPSHOTM</version>, it is correctly replaced in jar:jar and nbm:nbm goals (jar and nbm have names like "1.2.0.20100208100404"), but in nbm:manifest goal the generated OpenIDE-Module-Specification-Version is "1" and OpenIDE-Module-Implementation-Version is "1.2${buildNumber}-20100208".

Problem is, that project.getVersion() returns unreplaced version tag from pom.xml.

"Problem is, that project.getVersion() returns unreplaced version tag from pom.xml."

there must be something wrong in your setup, MavenProject project instance is always resolved by maven core and I suppose much more other things would not be working. I've tried locally and got the value correctly replaced in the manifest. I've tried with a simple standalone module, without any profiles..

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>nbmtest</groupId>
    <artifactId>testmodule1</artifactId>
    <version>1.${num}-SNAPSHOT</version>
    <packaging>nbm</packaging>
    <name>testmodule1</name>

    <properties>
        <num>2.3.4.5</num>
    </properties>
</project>

This example is working for me. But my setup is:

parent pom.xml:
profile snapshot, uses buildnumber maven plugin to set property ${num} to timestamp
default profile, that set property ${num} to empty string

module pom.xml:
<version>1.0${num}-SNAPSHOT</version>

If I run default profile, version is correctly replaced, constructed jar and nbm has right name and also in manifest file is correct string: "1.0-SNAPSHOT".

If I run snapshot profile, version is not correctly replaced, constructed jar and nbm has right name, but in manifest file is string "1.0${num}-SNAPSHOT" (project.getVersion() in NetbeansManifestUpdateMojo.java is returning "1.0${num}-SNAPSHOT".

It looks like I'm trying to replace ${num} using buildnumber-maven-plugin too late.

well, I fear everything will be too late for the build-number-maven-plugin. The project instance passed to plugins shall be immutable but currently is not.
In general plugins that attempt to modify the project instance currently succeed doing so (partly) but might stop working altogether in maven3.

can you just pass the property on cmdLine -Dnum=XXX? it would mess up the maven metadata on the local build, but if you need the nightly build job just to generate the jnlp thing, you might be safe.

As previously explained, OpenIDE-Module-Specification-Version is designed for all module updates that should be pushed to users. There is nothing stopping you from incrementing these versions during development. If you really want to test snapshots, then version numbers are essentially meaningless and you need to delete the local cache before starting the app.