Initial thoughts on what nbm-maven-plugin 4.0 could look like.


Possible Changes

Fix repository generation and usage

Do not use forcedVersion in populate-repository. Upload artifacts according to actual module specification version.

No more magic treatment for cluster *.pom dependencies. populate-repository should still create them, but they should declare dependency management, not actual dependencies. Use them with import scope so they are merely a shortcut for declaring that by default all NB dependencies come from e.g. RELEASE70. To actually include the full content of a cluster, declare a regular dependency on one or more kit modules (though see below note about require tokens).

Make AU and Maven interoperate.

  • Create an org.netbeans.spi.autoupdate.UpdateProvider for a remote Maven repository if that is feasible (would likely require use of Nexus Indexer).
  • Or, make a tool to create a standard update center descriptor to be uploaded into a repository and referring to its module contents (or some of them).
  • Remove support for repository form of distBase, which doesn't really work anyway: NBMs are still copied to output, and it assumes that your own modules are available in the same repository when they might be deployed elsewhere.

Use Maven Central:

Interpret *.external entries (especially with the m2 protocol) in NBMs when unpacking, create NBMs with this syntax whenever possible, and fix NBMs not using this syntax to do so whenever possible in populate-repository.


See NbmPackageStability for behavior of dependencies.

Maven version 1.5-SNAPSHOT should produce an OpenIDE-Module-Specification-Version with snapshot timestamp, e.g. 1.4.20101103132425, so you can publish updates from snapshots if you publish to a snapshot repository. TBD how to handle x.0-SNAPSHOT.

Enforce API compatibility scheme mechanically during verify phase.

  • MCLIRR-33 (proposed for inclusion in maven-enforcer-plugin) would be useful.
  • Or, adapt sigtest to this purpose.

Dependency management and project structure

No more nbm-application packaging; just a set of goals available on any module (such as a kit).

MKLEINT: I cannot imagine how assembling the application would work. Also please not that maven eventually needs a primary artifact in a project. That way nbm-application is a placeholder for uploading the zip of the application to repository. Without the packaging, you are pretty much without a chance there. I'm fairly sceptical here, I've done it before 3.x version of the nbm plugin and it never really worked.

Optional runtime-scope dependencies (on kit modules, typically) should be ignored for module dependencies but result in those modules (and deps) being included in app packagings. Thus, an app/branding/kit module project can indicate that it would like to ship with some feature enabled, but the user is permitted to disable it.

Figure out how to deal with OpenIDE-Module-{Requires,Needs,Recommends}:

  • Check that e.g. core.kit has regular deps on everything in the platform cluster.
  • Or, ensure that populate-repository resolves token deps and translates them into Maven deps.

MKLEINT: this basically creates a cyclic dependency, no?

No suite projects, nor related functionality such as nbm:cluster or nbm:run-ide.

Review current Maven -> NBM dependency translation. It is very complex, buggy (MNBMODULE-102), and the results are often surprising. Perhaps Maven 3.1 will allow the packaging plugin to control dependency resolution. Seems impossible now (discussion) but there may be other options (#204898).

Consider whether it is a good idea to attach the NBM as a secondary artifact with no classifier. This seems to confuse Nexus (hence the need for nexus-for-netbeans), and may be blocking interpretation of includesDependencies=true. MKLEINT: have you filed the issue against nexus?

Remove distinction between org.netbeans.api and org.netbeans.modules groups, if that becomes possible as a result of injecting a custom dependency resolution algorithm that does not treat compile scope as transitive. (Test scope would still be transitive, which is OK since package restrictions are not enforced for tests anyway. Would be nicer if Maven had a distinct test-runtime scope so that your test compile classpath is kept to a reasonable size.)


Make nbm:run-platform pick up modules from the reactor artifacts, i.e. ${module}/target/nbm/netbeans/${cluster} (or similar) rather than the local repository; no need to pack modules into NBMs or copy NBMs into the repo or unpack NBMs into ${app}/target/${name}/${cluster}. Should suffice to pass --clusters with one entry per component module. "Platform" modules, i.e. those not in the reactor, would be unpacked just once.

MKLEINT Anything reactor unfortunately means that the result of the build will differ based on where you stand.

(Ideally the NB module system would permit more flexible specification of modules to load during development: any combination of clusters, naked module JARs or OSGi bundles, NBMs, or unpacked class trees.)

Inject ValidateLayerConsistencyTest and similar generic app validation tests into the integration test suite. See org.jvnet.hudson.maven.plugins.hpi.TestInsertionMojo for an example.


Replace with map in plugin config. MKLEINT: manifest serves 2 purposes: allow setting additional values and supressing some values from being generated.

Replace module.xml with misc. plugin config. No dependency section. MKLEINT: module.xml is indeed evil. Killing it however currently kills implementation dependencies.

Factor out current harness code and templates used by mojos into its own Maven JAR project that could be used by both nbm-maven-plugin and the Ant-based harness. Then there would be no dependency of the plugin on NB releases just to fix or enhance build steps. This would also permit removal of the dependency of the plugin on Ant.

Alternate run modes

Provide a goal to perform OSGi translation according to NetBeansInOSGi.

Consider creating *.jnlp (and accompanying JARs) as a secondary artifact, so that webstart generation can simply aggregate descriptors from modules. This is important so that each module can customize its own JNLP semantics: bug #70477

Reports *

(Section not yet reviewed by nbm plugin devs)

Some plugins in the maven world offer reports, may be a nice feature to consider for nbm 4. (Ideas below to start discussion)

  • "maven dependencies/convergence.." report in netbeans module version schema
  • layer visualisation
  • apidoc limited to public package
  • aggregation of reports for nbm-application

Related Pages

Maven_NBM_comments - old evaluation of the 3.x plugin; some items obsolete.

MavenizingNbbuildProsAndCons - this would be a major motivation for an overhaul of the plugin.

DependencyBasedModuleIncludes - conceptual background for the biggest changes, though that page focuses more on the Ant harness; if done correctly in the Maven plugin and used in sources, the Ant harness could be put in maintenance mode and just kept for compatibility.

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo