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.
As described in this thread: http://netbeans.org/projects/www/lists/nbdev/archive/2011-06/message/38 None of the netbeans.org automated builds run on a Microsoft Windows system. According to Michael Nascimento, this has led to a condition in which a build succeeds on Unix, but fails on MS Windows. Michael also mentioned in this thread that the current setup produces not just failed builds, but also cases in which the IDE "is unusable for Windows due to OS-specific bug which [he feels] the test suite in NB would have shown immediately had it been run on Windows as well." Given that: 1. Microsoft Windows is widely-used, especially for community contributors. 2. While Java code should be platform-independent, there are certain characteristics of Microsoft Windows which are unique when compared to all other operating systems supported by NetBeans (which are all some variant of Unix). Filesystem conventions, such as path and file separators are good examples of this. 3. While there are many variants of Microsoft Windows (XP, Vista, 7; 32-bit, 64-bit, Home, Premium, Ultimate, etc.), just using the most popular/relevant one of these would probably be enough to catch most errors. 4. Defects are more expensive to fix as they get closer to a release. It is best to catch and fix problems early. I think it would be beneficial for NetBeans' automated build/test infrastructure to include at least one Microsoft Windows system.
(In reply to comment #0) > None of the netbeans.org automated builds run on a Microsoft Windows system. We already run automated tests for certain modules on Windows, but I think these use prebuilt binaries plus the binary test distribution. We ought to run at least a basic IDE build from sources on some CI job on a Windows slave too. None is available that I know of for either deadlock or bertram, or we would be doing so already (the Windows slaves used for tests are on the internal network and I have no admin access to these Hudson instances). > this has led to a condition in which a build > succeeds on Unix, but fails on MS Windows. Please file P1 bugs when you notice such problems. There was one temporarily recently but it was quickly fixed upon being reported by a Windows-using developer.