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.
When finding the app-project for a Maven-based NB Module project the method MavenNbModuleImpl.findAppProject() is executed. When examining open projects, it goes through each projects dependencies, INCLUDING transitive ones. This creates a false positive if you have a project which depends on a nbm-application project and you happen to have both of them open in the IDE. IMHO this method should only go through a project's direct dependencies. In other words: in that method the call to MavenProject.getArtifacts() should be replaced by MavenProject.getDependencyArtifacts().
we need to implement collision resolution when multiple apps contain the module. If these are dependent on each other, it's a bit easier, just pick the common ground I guess. with 2 independent apps it's non-deterministic. Maybe we need some manual way for users to say. "This is the app for opened modules."
Yes, true, but my point is that you can avoid some of these collisions by only looking at direct deps. Perhaps by having two versions of findAppProject, one that goes through all deps and one that only scans the direct ones. For example when finding the app for a branding project you would NEVER want to go through transitive deps whereas I can probably come up with the odd case why it can POTENTIALLY make sense for the case of a standalone project trying to find its app. Another suggestion would be to use the length of the dep path to choose between multiple candidates. If there are two app projects to choose from and one is found through a transitive dep and the other is found through a direct dep then for sure the method should return the latter, rather than giving up. Yet another suggestion is use the parent project and find the app project via that. Obviously this requires that parent project to be open as well and it is still not very conclusive as the module can of course be part of multiple projects all of which are open at the same time. But it still feels safer than looping through all deps (including transitive ones) of all projects. And yes, as you say, regardless of method if there are multiple candidates then it would be better to present a choice to the user rather than as now simply to give up. Enough of the rambling. I appreciate why there's no obvious solution.
what about "colocation" as we call it netbeans APIs? That means that projects under the same version control root folder would have precedence. I'm not entirely sure that the depth of the dependency trail is a deterministic measure, especially when dealing with multiple modules. We might end up with each "belonging" to different nbm-application. colocation sounds like it would work great for modules like branding. Not so much for large scale projects that are in multiple git repos. ui choice would be a bad thing to do in this method, it's being called in multiple scenarios with different or no ui. But having some sort of manual hint would still be a good option I believe. However manual hint needs to be most likely user specific (cannot be shared) as it needs a file or url reference to nbm-application project location
Integrated into 'main-silver', will be available in build *201404110001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/094b21b965de User: Milos Kleint <mkleint@netbeans.org> Log: #242147 use collocation query to decide which of multiple nbm-application open projects is the rigth one to associate with the current project