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.
Created attachment 140272 [details] Screenshot showing problem Please see attached screenshot. We have recently upgraded NetBeans from 6.9.1 to 7.3.1. I have an abstract class called 'AbstractFinderPanelAbsolute' which is defined in one of the module projects of my main project. There are 45 subclasses of this class in another module project. The screenshot shows one of these subclasses which you can see extends the abstract class. I can CTRL-Click on the 'AbstractFinderPanelAbsolute' and it correctly takes me to the source of that class. The screenshot also shows how the 'Find Usages' is not finding the occurences of these subclasses, however, it IS finding (correctly) references to the abstract class in the Maven repository. When I do a Refactor -> Rename, it only renames the occurrences listed in the Find Usage, thus creating build errors, because the subclasses are referring to the old name. Renaming it back again also does not seem to fix the Find Usages, although the build errors go away. I have tried completely removing the contents of my '.cache/netbeans/7.3.1' directory and restarted Netbeans, but the issue still persists. This never occurred in version 6.9.1. This has meant that we now cannot 'trust' what 'Find Usages' is telling us. And Refactoring could make incomplete changes.
as far as I can tell, the occurrences found in local repository just mean that some local repository artifacts are using the selected element. However that does not imply that the rename refactoring will somehow magically modify these jars in local repository. You need to modify the projects that produce these jars. And to include these projects into the refactoring scope 2 conditions apply: 1. the project needs to be opened in the IDE. 2. it needs to depend on the exact version of the project where the refactored element resides. Eg. if current version is 1.1-SNAPSHOT, depending on 1.0 won't cut it. I cannot see anything wrong here, please correct me if I'm wrong and reopen the issue.
No, no, no, no! I do not want to refactor anything in jars. Look at the title of this issue. I want to be able to find the usages of this class in the sources. I have both the containing project and the dependent project open in the IDE. Both projects are maven modules of a larger maven project. They are ALL open in the IDE, but find usages does not find the 45 subclasses of this class. I DON"T CARE ABOUT THE MAVEN REPOSITORY AS I HAVE THE SOURCE CODE OPEN RIGHT IN FRONT OF ME!!! (In reply to Milos Kleint from comment #1) > as far as I can tell, the occurrences found in local repository just mean > that some local repository artifacts are using the selected element. That's correct, but they need to be appearring in the usages at the top, but they don't. > However that does not imply that the rename refactoring will somehow magically > modify these jars in local repository. I don't want to modify the jars, I want to find the usages in the source. > You need to modify the projects that produce these jars. I don't want to modify the projects I want to find the usages! > And to include these projects into the refactoring scope > 2 conditions apply: > 1. the project needs to be opened in the IDE. Yes, it is. > 2. it needs to depend on the exact version of the project where the > refactored element resides. Eg. if current version is 1.1-SNAPSHOT, > depending on 1.0 won't cut it. All the module projects are the SAME version because they are all parts of the same main project. > I cannot see anything wrong here, please correct me if I'm wrong and reopen > the issue. Reopening
is your issue related to issue 207349? specifically, are you using dependencies with classifier, maybe the shade plugin or anything similar that is outside of the usual "B depends on main artifact jar of A"?
I do not know what "dependencies with classifier" are, and I have never heard of the "shade plugin", so I guess the answer is No. The main project has a pom.xml header as follows: <groupId>uniworks</groupId> <artifactId>uniworks</artifactId> <packaging>pom</packaging> <version>1.1.8-SNAPSHOT</version> With a list of modules that has: <modules> ... <module>resources</module> ... <module>ui</module> </modules> Module 'resources' contains the class "AbstractFinderPanelAbsolute". It has POM headers: <groupId>uniworks</groupId> <artifactId>uniworks-resources</artifactId> <packaging>bundle</packaging> <version>1.1.8-SNAPSHOT</version> Module 'ui' (which contains the 45 subclasses of 'AbtractFinderPanelAbsolute') has POM headers as follows: <groupId>uniworks</groupId> <artifactId>uniworks-ui</artifactId> <packaging>jar</packaging> <version>1.1.8-SNAPSHOT</version> and has 'resources' as a dependency: <dependency> <groupId>uniworks</groupId> <artifactId>uniworks-resources</artifactId> <version>${project.version}</version> <scope>compile</scope> </dependency> where {project.version} is defined as '1.1.8-SNAPSHOT'. This worked fine in 6.9.1. Let me know if there is anything else I can tell you.
By the way, is there any way to exclude the local Maven repository from the 'Find Usages'? We only want to see the usages found in the source, not the jars. 6.9.1 never included the Maven repository and that's the way we would like to have it now, as we were happy with the way 6.9.1 worked.
(In reply to duncank from comment #4) > > Module 'resources' contains the class "AbstractFinderPanelAbsolute". It has > POM headers: > > <groupId>uniworks</groupId> > <artifactId>uniworks-resources</artifactId> > <packaging>bundle</packaging> > <version>1.1.8-SNAPSHOT</version> by any chance does this project show any problems? (yellow triagle icon badge + Resolve project problems action in popup?) the problem name would be "Export-Package/Private-Package contains packages from dependencies" The description of the problem as should appear in the Resolve problems dialog: "When the final bundle jar contains classes not originating in current project, NetBeans internal compiler cannot use the sources of the project. Then changes done in project's source code only appears in depending projects when project is recompiled. Also applies to features like Refactoring which will not be able to find usages in depending projects." > > This worked fine in 6.9.1. likely because this code was not inplace back then and compilation false error markers were appearing in depending projects. If you believe your setup is different, please attach a sample project demonstrating the problem that is equal to your own in-house setup.
(In reply to Milos Kleint from comment #6) > (In reply to duncank from comment #4) > > > > Module 'resources' contains the class "AbstractFinderPanelAbsolute". It has > > POM headers: > > > > <groupId>uniworks</groupId> > > <artifactId>uniworks-resources</artifactId> > > <packaging>bundle</packaging> > > <version>1.1.8-SNAPSHOT</version> > > > by any chance does this project show any problems? (yellow triagle icon > badge + Resolve project problems action in popup?) > > the problem name would be "Export-Package/Private-Package contains packages > from dependencies" > The description of the problem as should appear in the Resolve problems > dialog: > "When the final bundle jar contains classes not originating in current > project, NetBeans internal compiler cannot use the sources of the project. > Then changes done in project's source code only appears in depending > projects when project is recompiled. Also applies to features like > Refactoring which will not be able to find usages in depending projects." Yes, that is exactly what I have got with the 'resources' project. OK, so I looked at the Exports for the 'resources' bundle and sure enough there was an export of an imported third-party library. I removed that export (which wasn't actually required anyway) and recompiled the 'resources' project. Find Usages still did not see the sub-classes. Then I recompiled the 'ui' project (which depends on 'resources') and the Find Usages now included the sub-classes in 'ui'. Great! So to prove that the problem was the export, I added the export back in again, so it was same as at the start. Recompiled 'resources' and 'ui' and the Find Usages STILL shows the sub-classes correctly!! In other words, I am back to the exact same source code that I started off with, but NetBeans now sees the usages!!! That is ridiculous! How are we supposed to know when Find Usages is working correctly or not? The yellow triangle means nothing, as it is now back on the 'resources' project, but the Find Usages is working fine! > > > > This worked fine in 6.9.1. > > likely because this code was not inplace back then and compilation false > error markers were appearing in depending projects. Yes, but in 6.9.1 there was usually something that I could do to 'fix' the false compilation errors. Usually by recompiling one or other of the projects. Now without those red error badges, there is no visual cue that something is wrong 'under the hood'. I'd rather have the red badges! At least they were an indication that something's not right. This is a massive step backwards as far am I'm concerned
(In reply to duncank from comment #7) > > That is ridiculous! How are we supposed to know when Find Usages is working > correctly or not? The yellow triangle means nothing, as it is now back on > the 'resources' project, but the Find Usages is working fine! > that's the only bug I'm willing to admit. Apparently something is not propagating changes correctly when the only thing that changes is the source preference boolean flag. BTW: rebuilding a project is in this case equivalent to Reload POM action on project popup. > > > > > > This worked fine in 6.9.1. > > > > likely because this code was not inplace back then and compilation false > > error markers were appearing in depending projects. > > Yes, but in 6.9.1 there was usually something that I could do to 'fix' the > false compilation errors. Usually by recompiling one or other of the > projects. > No, in the case when you actually *used* the 3rd party packages in your dependent projects, you would get red error marks on all usages *indefinitely*. No rebuilding would *ever* help. So I'm changing this to a P3 to fix the propagation of changes. issue 198951 is related here, it suggests we should mark the non-linked dependency project in the depending project's Dependencies nodes as well, not just the actual project.
> So I'm changing this to a P3 to fix the propagation of changes. issue 198951 > is related here, it suggests we should mark the non-linked dependency > project in the depending project's Dependencies nodes as well, not just the > actual project. Well, you can downgrade it all you like, but as far as I'm concerned Find Usages is now officially broken and I won't be able to trust it anymore. In previous versions of NetBeans I was always confident that Find Usages and more importantly Refactoring would 'do the right thing'. I can't say that now. Time to download the latest version of Eclipse to see where they're up to now.
http://hg.netbeans.org/core-main/rev/1848f5d9e342 adds listening on preferSources() changes + improves the collection of changes. Additionally we have a visual clue on project that is using shade plugin or bundle plugin in ways that are unsupported. A dependency node linking to the project where preferSources() is false (due to use of classifier, shade plugin, bundle plugin etc) is visually marked as well, tooltip reveals the problem description. the issue is considered fixed, nothing will change in the way projects are actually linked together. The problem thereof outweight the benefits (as is described above).
Integrated into 'main-silver', will be available in build *201401300001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/1848f5d9e342 User: Milos Kleint <mkleint@netbeans.org> Log: #236164 when preferSources changes, fire a change event. also rework the chnage firing loop to make sure none of the changes evade us due to thread concurrency