Clarification:

The netbeans app bash script will look under target/appname/platform*/lib/ for the nbexec binary

After running nbm:cluster-app I have to copy the following files manually to the corresponding places under target to make nbm:run-platform work:

$NB_INSTALLATION/platform9/lib/nbexec
$NB_INSTALLATION/platform9/lib/boot.jar
$NB_INSTALLATION/plafrom9/core/core.jar

what repository are you using for the assembly of the application? did you generate it yourself? with what version of nbm-maven-plugin?

nbm-maven-plugin version:3.0
repository: http://bits.netbeans.org/maven2/
nb rcp: RELEASE65

and by unix (in issue summary) you mean MAC OSX alone or is it also not working on linux?

I have not tried it on Linux but it should be the same netbeans-start-script so I cannot se how it could work on any unix flavour.

We added org-netbeans-core-windows as a dependency to our nbm-application project and the missing came with either that dependency or one of the transitive dependencies from the module.

Problem solved.

what dependencies did you have with the nbm-application project? the boot.jar and core.jar shall be on the platform cluster pom's dependency set. if not the populate-repository goal has a problem.

We only had transitive dependencies from our application modules.
When we added these two dependencies to the app it worked:
<dependency>
<groupId>org.netbeans.modules</groupId>
<artifactId>org-netbeans-core-windows</artifactId>
</dependency>
<dependency>
<groupId>org.netbeans.modules</groupId>
<artifactId>org-netbeans-modules-editor-mimelookup-impl</artifactId>
</dependency>

I would guess that core-windows has dependencies on core and bootstrap.

When I look at the library view in netbeans/mevenide i cannot find core.jar or boot.jar even though it now works. org-netbeans-bootstrap.jar and org-netbeans-core.jar are among the dependencies though.

well, relying on transitive dependencies only is not 100% bulletproof (as you figured) there are modules that are required by the running application but which are not reachable by transitivity. These typically provide implementations of services defined in other api modules. core-windows is a nice example. no module depends on it, but it's crucial to the running app as it implements the window system.

a safer way to define what your application is composed of is it declare dependency on the whole cluster (org.netbeans.clusters groupid) and then eventually selectively exclude stuff you don't want at runtime..