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: | Subprojects not listed when project is closed | ||
---|---|---|---|
Product: | projects | Reporter: | Jiri Sedlacek <jis> |
Component: | Maven | Assignee: | Jesse Glick <jglick> |
Status: | RESOLVED DUPLICATE | ||
Severity: | blocker | CC: | issues, jglick |
Priority: | P2 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: |
Description
Jiri Sedlacek
2009-05-04 15:26:05 UTC
As mentioned in Issue 164140 this doesn't follow the behavior described in SubprojectProvider.getSubprojects() API documentation at http://bits.netbeans.org/dev/javadoc/org-netbeans-modules-projectapi/org/netbeans/spi/project/SubprojectProvider.html#getSubprojects(): application/pom.xml reports to depend on module1/pom.xml and branding/pom.xml when opened, so the projects can clearly be considered to be dependencies of application/pom.xml and should always be listed as long as the projects configuration is unchanged. If the inconsistency cannot be fixed by caching the correct list of subprojects on maven project side and the current state is considered to be correct, then this bug should be assigned to Projects/APIdocs as the current API documentation is incorrect. I think mentioning that the list of dependencies can change during project lifecycle would be enough, changes can be tracked using SubprojectProvider.addChangeListener(). But that would be an incompatible change, I'm afraid... As discussed in issue #164140, that bug is in Profiler and is not the responsibility of the maven module, which is permitted to change the result of SP without notice. The API documentation says only that the list is "at the discretion of the project" and specifies nothing about when and why the result might change. Nonetheless it would be desirable for the result not to become the empty set merely due to projects being closed. Reassigning to default owner. Probably should use same cache system as described in bug #186024. Would be fixed by that patch, I think. *** This bug has been marked as a duplicate of bug 186024 *** |