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.
This issue refers to the discussion taken place specified by the URL. I had downloaded the platform10, harness cluster from http://bits.netbeans.org/download/trunk/nightly/latest/zip/moduleclusters/ I have extracted them in one folder and then, added this platform in NB 6.7 RC2. Then, when I created a Module against this platform, I saw the following output in the console; . . . Installation = C:\Documents and Settings\nvarun\My Documents\NetBeansProjects\DevSample\build\cluster C:\Documents and Settings\nvarun\Desktop\NetBeans Dev\harness C:\Documents and Settings\nvarun\Desktop\NetBeans Dev\platform10 C:\Documents and Settings\nvarun\Desktop\NetBeans Dev\platform10 . . . Similarly, Tom Wheeler *was* able to reproduce the bug in which the 'platform10' cluster was listed twice in the startup messages of his suite: Installation = C:\Documents and Settings\twheeler\My Documents\NetBeansProjects\sample67suite\build\cluster D:\temp\nb67plafclusters\plaf\platform10 D:\temp\nb67plafclusters\plaf\platform10
Can evaluate in apisupport, though root issue might be in launchers or startup code.
I looked at the 6.7 RC3 sources and figured out what's causing this. It turns out that it's not really a bug, but more a cosmetic issue that can be confusing for platform developers. As you see from Varun's console output, it appears that the "platform10" cluster is being included twice. I looked at TopLogging.java and found that the "Installation" output is created by splitting the "netbeans.dirs" system property on filesystem path separators. Based on this, one might conclude that the root cause is that the netbeans.dirs system property includes the platform10 cluster twice. But a little experimentation shows this is not the case. The problem is actually on line 271 where it writes the value of CLIOptions.getHomeDir() to the print stream without any prefix or label, so it looks like a continuation of the "Installation" value (especially so since it is indented to the same level). I am setting this to P4 because IMHO it's nothing more than a cosmetic issue (and according to Hg, it has been this way for ~ 2 years). However, the solution should be very simple: just write a newline and a label before printing the CLIOptions.getHomeDir() value similar to what I show here: BEFORE: ps.print( " Installation = "); // NOI18N String nbdirs = System.getProperty("netbeans.dirs"); if (nbdirs != null) { // noted in #67862: should show all clusters here. StringTokenizer tok = new StringTokenizer(nbdirs, File.pathSeparator); while (tok.hasMoreTokens()) { File dir = FileUtil.normalizeFile(new File(tok.nextToken())); if (dir.isDirectory()) { ps.print(dir); ps.print("\n "); //NOI18N } } } ps.println(CLIOptions.getHomeDir()); AFTER (only the last three lines are changed from the original): ps.print( " Installation = "); // NOI18N String nbdirs = System.getProperty("netbeans.dirs"); if (nbdirs != null) { // noted in #67862: should show all clusters here. StringTokenizer tok = new StringTokenizer(nbdirs, File.pathSeparator); while (tok.hasMoreTokens()) { File dir = FileUtil.normalizeFile(new File(tok.nextToken())); if (dir.isDirectory()) { ps.print(dir); ps.print("\n "); //NOI18N } } } ps.println(); ps.print( " CLIOptions home dir: = "); // NOI18N ps.println(CLIOptions.getHomeDir());
Tom, thanks a lot for finding this out! Passing to correct component.
No, it is intentional that CLIOptions.getHomeDir() (i.e. ${netbeans.home}) is printed where it is. The problem is that ${netbeans.dirs} contains the platform cluster _once_. netbeans.dirs is supposed to contain _only_ additional clusters (i.e. its value is always implicitly combined with that of netbeans.home). I suspect a bug in the build harness, but might be in nbexec. Resetting priority because this is more than just a cosmetic issue.
Working OK for me. Reopen if you have steps to reproduce from scratch.