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.
Summary: | CV test org.netbeans.test.ide.GeneralSanityTest.testNoWrites is failing constantly on Windows. | ||
---|---|---|---|
Product: | javacard | Reporter: | Tomas Danek <musilt2> |
Component: | Java Card | Assignee: | _ tboudreau <tboudreau> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | jtulach, mmirilovic |
Priority: | P1 | Keywords: | TEST |
Version: | 7.0 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: | log |
Description
Tomas Danek
2010-09-30 11:50:50 UTC
This is by design. Since the RI was not in the standard distro, we did not address this for 6.x. Basically, the RI adds properties files that contain the fully qualified path to the RI JARs - they need to be used directly from Ant scripts. There is no way to do this declaratively. However, registration is delayed until 10 seconds *after* the main window opens. Not a major issue. Yarda, could you please help with this test ? Thanks in advance. The approaches I can think of to fixing this would be: - Actually provide some general purpose infrastructure for things that need to write into $USERDIR/build.properties and other places after installation. Anything that needs to write fully qualified paths into the NetBeans install needs this - otherwise projects are not buildable from the command-line). The only reason we don't have this problem in JavaPlatform is because the default Java platform is available from system properties and a java binary must be on the system path or NetBeans itself wouldn't be running. - Find a way to move writing this stuff to the installer (ModuleInstall or something else will still have to check that it is really there, though) - Try to register a lazy fake-java-platform that replaces itself the first time something tries to use it (I prototyped this, but something in the Java modules was aggressively trying to call all installed platforms after startup, so I think it cannot be lazy without some help from the Java infrastructure) - and if you do this, make sure fake classpath info or whatever you need to make it lazy isn't cached by the Java infrastructure and used later or things will break. What is actually happening is this: - RI bundle contains a full install of the Java Card RI - Java Card platforms and cards are properties files in the sysfs - Those properties files are loaded directly by Java Card project Ant scripts - the customizers for Platforms and Cards simply read and write the data the Ant script uses - Java card projects get their entire definition of what card and platform to run on from them - The location to look them up in is stored by name in $USERDIR/build.properties - i.e. a Java Card project's ant script is looking for jcplatform.${platform.name}.location (I forget the actual property names) - which is a path on disk to the userdir *** This bug has been marked as a duplicate of bug 187023 *** Should be included in M2 |