This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Alluded to in bug #190992 but really a separate issue. Currently from a Maven nbm-application project you need to pass to Surefire: <configuration> <systemProperties> <property> <name>cluster.path.final</name> <value>${project.build.directory}/${brandingToken}/${brandingToken}:${project.build.directory}/${brandingToken}/platform</value> </property> </systemProperties> </configuration> (This is part of the current archetype.) But that is pretty ugly, and also forces you to hardcode a list of cluster names, which could be awkward if you are using several clusters. Would be nicer to define just e.g. <name>installation</name> <value>${project.build.directory}/${brandingToken}</value> and have NbModuleSuite (in findPlatform & findClusters) take all appropriate subdirectories as clusters. Nicer still would be if NbMS could figure out the install dir for a Maven invocation without being passed any special property, but I'm not sure if this is straightforward.
Not mentioning that the value of <value>${project.build.directory}/${brandingToken}/${brandingToken}:${project.build.directory}/${brandingToken}/platform</value> is wrong if you include modules from other clusters than only the platform... The cluster.path.final has been introduced to fix bug 153178 to allow filtering out clusters that are not used by the suite's platform.properties. However, as far as I understand Maven solution, this is not necessary at all. Maven unpacks just those NBMs that are really included in the application. As such there should be no reason to filter anything out. Right?
(In reply to comment #1) > the value of > <value>${project.build.directory}/${brandingToken}/${brandingToken}:${project.build.directory}/${brandingToken}/platform</value> > is wrong if you include modules from other clusters than only the platform Exactly my point - if you start to use other clusters, you have to edit this field in the POM accordingly. > Maven unpacks > just those NBMs that are really included in the application. As such there > should be no reason to filter anything out. Right? Right. There are no excludes in an nbm-application; you can depend on any mix of modules and cluster POMs. So whatever is in the build area should really be used.
> Right. There are no excludes in an nbm-application; you can depend on any mix > of modules and cluster POMs. So whatever is in the build area should really be > used. That means you don't need any tricks created for bug 153178. Just make sure the logic is disabled. I lived under impression that if the cluster.path.final property is not defined, the NbModuleSuite will pick up everything in the "installation" directory.
(In reply to comment #3) > I lived under impression that if the cluster.path.final > property is not defined, the NbModuleSuite will pick up everything in the > "installation" directory. It has to find that directory somehow. Currently, when run from Maven, that happens because ${cluster.path.final} is set.
I guess in Ant mode, the platform directory is found as Class<?> lookup = Class.forName("org.openide.util.Lookup"); // NOI18N File util = new File(lookup.getProtectionDomain().getCodeSource().getLocation().toURI()); Assert.assertTrue("Util exists: " + util, util.exists()); return util.getParentFile().getParentFile(); we can indeed use similar code to locate the clusters if cluster.path.final is missing.
This only works in the current Ant harness because the classpath entry for org-openide-util-lookup.jar happens to be in platform/lib. As in bug #190992, that assumption does not hold for the Surefire test harness used by Maven; you would rather get ~/.m2/repository/org/netbeans/api/org-openide-util-lookup/ as the return value.
Not for 7.0.
It is a bit tricky to come up with a good test case, because when I try making a functional test using jellytools.ide (testing a module using core.ide), it passes even when the ide cluster is not in cluster.path.final; the only detectable difference is that the ide cluster is not included in the startup messaging printed to stderr.
core-main #7b05b91478d1
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/7b05b91478d1 User: Jesse Glick <jglick@netbeans.org> Log: #194794: More convenient alternative to ${cluster.path.final} for use from Maven