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.
The rename resulted in many exceptions see: http://statistics.netbeans.org/analytics/detail.do?id=207032 NOTE: The rename was done from NB, no console commands at any time. This is very different from others related to exception. Initial directory structure: PlatformApp SwissEphemerisService SwissEphemerisWrapper so the wrapper is in the directory of the service Renamed project and it's directory from "SwissEphemerisService" to "ephemeris.swiss.service". This resulted in PlatformApp ephemeris.swiss.service SwissEphemerisWrapper A problem is that not all references to SwissEphemerisService are changed. In particular, in the PlatformApp nbbproject/project.properties after the project-dir rename, there is project.org.metawb.ephemeris.swiss=../ephemeris.swiss.service project.swisseph=../SwissEphemerisService/SwissEphemerisWrapper Note that project.swisseph was not fixed up PS. there were also some references in ephemeris.swiss.service/nbproject/private/private.xml not fixed up. Probably a don't care, or close to it.
In addition to platform-app's project properties not getting all fixed up A suite-component rename mishandles platform-properties. In this example, MetaWB is a suite-component before rename $ ls MetaWB/nbproject/ build-impl.xml* private/ project.xml* genfiles.properties* project.properties* suite.properties* after rename $ ls metawbx/nbproject/ build-impl.xml* platform.properties* project.properties* suite.properties* genfiles.properties* private/ project.xml* Observe that after the rename - there is now a platform.properties file. - suite.properties has been removed and added (see hg st below) $ pwd /a/src/wb-dev/wb/metawbx/nbproject $ hg st|egrep 'suite.properties|platform.prop' A metawbx/nbproject/platform.properties R MetaWB/nbproject/suite.properties ? metawbx/nbproject/suite.properties $ hg diff platform.properties diff --git a/metaphysical.workbench/nbproject/platform.properties b/metawbx/nbproject/platform.properties copy from metaphysical.workbench/nbproject/platform.properties copy to metawbx/nbproject/platform.properties
1) the more
... OMG, login interrupted my last comment, so once again ... 1) the more "serious" problem described in the first comment: when renaming a project only that project is taken into account, no possible projects under its project folder are handled specifically. In other words, the project folder moves but only the moved project's relations to the suite are handled. In order to fix this i guess org.netbeans.modules.apisupport.project.ui.ModuleOperations would have to specifically handle also all projects under its project folder it can know of. But it will never work reliably, only projects relevant to the moving project's suite may be handled, no other "unrelated" projects can be notified. That's why i think the best would be for users to keep the folder structure flat and do not nest projects unnecessarily. Ernie, is it really that necessary to keep projects nested this way? 2) another story, please file a separate issue.
BTW, #2 - platform.props created - should be fixed with the fix for #251110
(In reply to Ondrej Vrabec from comment #3) > ... > That's why i think the best would be for users to keep the folder structure > flat and do not nest projects unnecessarily. I was in the process of doing that when I ran into this problem. If this is not a supported configuration, it would be nice to produce a warning or to prevent the ide from setting it up. I suppose I assumed it was OK, since the nesting of modules in a suite is handled. I can see how if unrelated projects are nested, there would be more issues.
Sorry, we do not support nested apisupport projects, there should definitely be a warning when creating project. But i don't think it's that serious, not very often and if happens the fix is quite easy, just change the references in project.properties. Decreasing to P3