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.
After deleting or moving a module suite (modules not located underneath it), it is impossible to either fix the suite that has been changed, or add the modules that were in it to a new suite - any interactions with those projects now silently produce this in the log: java.io.IOException: Project in C:\tutorial\dev\hexeditmodule does not appear to be listed in its own module list; some sort of misconfiguration (e.g. not listed in its own suite) at org.netbeans.modules.apisupport.project.NbModuleProject.<init> (NbModuleProject.java:122) at org.netbeans.modules.apisupport.project.NbModuleProjectType.createProject (NbModuleProjectType.java:41) This exception should be user-visible if the user needs to edit something, should say what files the problem is in (even if just logged, so there is at least a chance of fixing it), and should try to fix it or do something reasonable if nothing else can be done. Note - changing project.xml <suite-component/> to <standalone/> does not help too much - now the exception is INFORMATIONAL *********** Exception occurred ************ at 7:40 AM on Aug 2, 2005 java.io.IOException: No netbeans.dest.dir defined in C:\tutorial\dev\hexeditmodule at org.netbeans.modules.apisupport.project.universe.ModuleList.findOrCreateModuleL istFromStandaloneModule(ModuleList.java:449) at org.netbeans.modules.apisupport.project.universe.ModuleList.getModule I finally succeeded by manually adding netbeans.dest.dir=C:\\tutorial\\platform to project.properties, and then got java.lang.IllegalArgumentException: File MasterFileObject@69d7ee [file:/C:/tutori al/dev/hexeditwrapper/nbproject/private/suite-private.properties] already exists . (it should probably just rewrite this, not die) Now I can add the modules to the suite, but building the suite fails: C:\space\netbeans\harness\suite.xml:25: Cannot open C:\tutorial\dev\hexeditwrapperC\nbproject\project.xml no idea where "hexeditwrapperC" came from, Find doesn't find any occurance of that string in the suite. Sigh. The point to all this sound and fury: Occasionally someone will delete a suite, or relocate some files. This shouldn't totally hose the modules that belonged to it.
Probably WONTFIX for now; there is no GUI yet for moving module or suite projects. Note: each module points to its suite (in suite.properties or suite-private.properties) and each suite points to its modules also (in project.properties or private.properties). Don't know what "C:\tutorial\dev\hexeditwrapperC\nbproject\project.xml" is but it's probably a result of a bug in the suite properties customizer code which is already filed: missing separators. Also note: netbeans.dest.dir should always be defined in some *private.properties if absolute. private.properties for a suite, platform-private.properties for a standalone module. May not be defined for a suite component module. Don't know about the IAE; may be a separate bug if you include complete stack trace and info to reproduce.
The main thing is, intrusive or not, it would be better to notify this: java.io.IOException: No netbeans.dest.dir defined in C:\tutorial\dev\hexeditmodule to the user and offer to fix it - just, say, put the default value for netbeans.dest.dir wherever it needs to be. Failing silently and leaving the user to flail around trying to figure out what needs to go where. Not supported is one thing, leaving the project in a nearly impossible-to-fix state is worse. If I screw up and mangle a suite, that shouldn't make the projects that were in the suite permanently unopenable unless I do a bunch of black magic. Better "Cannot find suite <path> for module foo. [Locate] [Remove Suite Reference/Make Standalone] [Do nothing]" wouldn't be too hard - if you're parsing it, you know where the bad data is. At the very least, say what file the key/value is missing from.
There is a plan to add a proper Broken References dialog for module and suite projects. I don't think we have time to do it for 4.2 though, sorry. The IOException was never intended as a user-level error.
Fine. IMO, offering to clobber the setting with *something* that will make the project usable again in 4.2 is must-have. It doesn't have to be a full fledged, nice Resolved References dialog, just make the thing into an openable stand-alone project, if the user says no, record for the duration of the session that they were warned. I tore my hair out on variations of this for several hours prepping for the oscon talk...and I *know* what I'm doing. If the only option to recover a project is to cut and paste all the sources into a newly created project, we're going to lose users. Supported or not, people are going to run into this.
Will not touch for 5.0. Will be GUI support later. Exact behavior may have changed somewhat since you reported this, but expect exceptions. *** This issue has been marked as a duplicate of 63151 ***
fix after 5.0, verified duplicate.