Bug 228560

wontfix. AFAIK the open projects is the scope for refactoring plugins intentionally. 

In any case not something that could be done on maven level alone but would have to be rewritten globally, including UI to enable and disable it.

So in which Product group would this enhancement request make sense?

I think this is still a valid request, since hardly anyone would have all subprojects in a large project open, since it's just too much for some IDE's (includeing Netbeans) and it's also mostly not necessary.

But if you want to refactor some code, you simple cannot rely on the IDE anymore, when doing 'Find usage' (or even refactorings, eg rename) since it will only cover 'OPEN' projects. 

So you have to go back to simple 'Find...' action. But does this make sense to you? Whats the point, why do I have refactoring (or in this Enhancement request 'Find usage') functionality at all if I can not use it in large projects too?

Thus it would make sense to enhance UI and backend by adding the possiblity to not only do 'Find usage' on open projects by adding an option in the UI of the popup to look in 'include all submodules'.

Don't you agree?

(In reply to comment #3)
> I think this is still a valid request, since hardly anyone would have all
> subprojects in a large project open, since it's just too much for some IDE's
> (includeing Netbeans) and it's also mostly not necessary.
> But if you want to refactor some code, you simple cannot rely on the IDE
> anymore, when doing 'Find usage' (or even refactorings, eg rename) since it
> will only cover 'OPEN' projects. 
> So you have to go back to simple 'Find...' action. But does this make sense to
> you? Whats the point, why do I have refactoring (or in this Enhancement request
> 'Find usage') functionality at all if I can not use it in large projects too?
> Thus it would make sense to enhance UI and backend by adding the possiblity to
> not only do 'Find usage' on open projects by adding an option in the UI of the
> popup to look in 'include all submodules'.
> Don't you agree?

I personally do not agree, as this will give developers different problems. One would be the performance of refactoring, as all these projects need to be scanned and indexed (which you already stated is not something you want). Another problem would be versioning, when a refactoring will make changes to projects not open in the ide, how will the developer be informed files are changed and need to be pushed to their versioning system?

(In reply to comment #1)
> wontfix. AFAIK the open projects is the scope for refactoring plugins
> intentionally. 
> In any case not something that could be done on maven level alone but would
> have to be rewritten globally, including UI to enable and disable it.

If this is something that is really necessary for maven, it can be done on the maven level;

http://bits.netbeans.org/dev/javadoc/org-netbeans-modules-refactoring-api/apichanges.html#ServerSideQueries

Well from a developer point of view it's quite simple, I think:
.) Say, my project consists of approx 30 modules (checked out via SVN)
.) Somewhere in my dependency tree I want a change (rename) or want to do 'Find usage'. From a/the dropdown in the dialoge I select 'Search in all dependent projects'. 
.) A message will be displayed, that this option could take a bit longer...
However I will get ALL occurances (For 'rename' refactoring I won't get any compile errors later)

Regarding SVN - that's a different problem, that would need solving. 
A) In our case we have a topmost folder that contains the hole source with all the submodules as child. I need to check for changes here, since Projects view only shows SVN changes per project not the submodules, which is IMHO unsatisfying. But that's how it is right now
B) For a flat structure you might need other notifications.

In both cases if I do a refactoring, the user should be notified that changes in 'closed projects' where made. But that's ok, since that's what he choose when he selected 'Search in all dependent projects'.
The IDE could suggest to open all projects where changes had been made.

In case A) I could still decide not to open these projects, since I can find SVN updates via 'Favourites' and I am able to compile all projects via the top most parent project.
In case B) I would say decide to open these (changed) projects since then I can compile and commit them via SVN. 

But the MOST important facts is resolved:
.) I can find ALL occurances via 'Find usage'
.) Refactor through the WHOLE project tree, which prevents incomplete changes and compile errors and a lot of frustrations.
.) I don't have to open EVERY single project to accomplish this.

(In reply to comment #5)
> <snip>
> .) I don't have to open EVERY single project to accomplish this.

But wouldn't that be a good solution? Opening required projects can be done with a single action in the ide.

Actionally, not really, since, I really don't need maybe 30 or more submodules open. Since this just clutters the Project view drags down IDE performance. And I also don't need them open, since I am not working in those other projects. So I only really would need to open all projects for refactoring or 'Find usage'. Whats the point in that?

Why can't the IDE take care of this? Why do I need to know how the IDE works internally in order to get tasks done? So in this case if I want to refactor or 'Find usage' I need to 
1.) Open dependent projects (even if I don't use them'
2.) Do refactorings
3.) Close dependent projects again.

Why do I need to do 1 + 3 at all, the IDE can do that for me. Don't you agree?

(In reply to comment #7)
> Actionally, not really, since, I really don't need maybe 30 or more submodules
> open. Since this just clutters the Project view drags down IDE performance. 

Well, that's the baseline in the whole discussion. Open or not, the IDE performance WILL go down as the additional projects/source root will have to be scanned and processed. There is no shortcut.

Given that you want to changed code in the other 20 modules, you are effectively working on them. Open projects is a natural and intuitive scope definition.

If you see it this way, then you are right, but I do not need to open them by hand first in order that Refactoring tasks work correctly, but the IDE takes care of these actions.

For
.) Find usage:
EXPEXTED: I don't really need to open these 'dependent' projects, since I only want to see, where the class/method is used.
ACTUAL: I have to first open all dependent projects. The do 'Find usage' and then close those projects by hand - Really cumbersome!

.) Refactorings:
EXPECTED: The Preview will show me all the modules where the class/method I want to refactor are in. I still can decide if i want to refactor or not. If I do, the IDE will take care of most/all the detailed steps to continue
ACTUAL: I first need to open all dependent projects. Then refactor. (Maybe I decide not to refactor, since I find there are too many changes, but at least I see where it would refactor). If only a change was only found in one of the, say, 20 dependent modules, then I had to open 19 modules for no purpose at all. Finally I have to close all of them again.

I actually think that the current approach takes up a LOT more resources, since I have to open all dependent projects and the IDE loads everything it needs for GUI and so on. 
The proposed approach, will not load all the GUI things, but only the source dependencies (and maybe some other things) and if a code has been changed, then only the changed modules may have to be openend in the GUI, which will in most cases be less then the 'all dependent' modules.

compared to classpath scanning, GUI costs peanuts..

also please note that while "Where used" has customizable scope, refactorings don't. (which makes it a refactoring issue again)

In 'Find usage' the custom scope only works for 'open project', thus you can only reduce scope

Further, Find usage and refactoring really DO NOT work (since results are incomplete)  if you currently don't have all projects open, that have the current module as a dependency. Therefore I always have to THINK FOR Netbeans which projects I need to open in order that Find usage and refactorings work properly. Isn't that true?

So if there is no choice anyway for these actions to work properly, why not let netbeans do the work for me, but without actually openening the projects in the GUI?

Apperently you seem to have all projects open all the time. Since you don't seem to see the necessity of this.

But with the amount of submodules in our project, you tend to loose the proper overview, that's why I'd like to not being forced to open all modules

Yes, it is possible to implement this enhancement and I would say, that it is valid.
But! 
Implementation of this enhancement will introduce performance issues (since we will need to keep our internal structures even for projects, that are not open) and our decision was not to go this way.

I propose to close this issue, since I don't know any contributor willing to implement it and not cause serious performance regressions.

Well I didn't propose that the datastructure is to kept the whole time. Since IMHO the datastructure needs only to be present when I select the option 'Include all dependent projects' when I want to 'Find usage' or 'Refactor...' and I also proposed, that the user will be notified, that this action will be more timeconsuming.

However the great advantage would be that 'Refactoring' and 'Find usage' would actually work for all projects in the dependency tree. Otherwise I would get compileerrors somewhere else after eg a rename... (for the closed dependent projects).

And I really don't see an additional preformance issue, since if you want these actions to work properly you need to open all projects anyway and that really drags down performance already, doesn't it?

And notice, I do NOT suggest to keep the datastructure of ALL closed projects in memory, but only load the datastructure dynamically for those projects that are affected by the dependency tree (for me, eg maven) when I start the refactoring.... And after the refactoring (or find usage) the additional datastructure could even be disposed of.

The alternative is to all this would be plain old search and replace - but whats the point?

Yes, you are right again.
But still don't see anyone willing to do that.

Well, if you close this enhancement request, then it's gonna be lost. If you keep it open, at least there is a chance it might pop up in one of the future releases :)

Well, I don't care :)
Truth is, that none is going to implement this and keeping it open gives false expectation, that it will be implemented in near future.

Apparently...

I wonder if this is only maven related anyway and not a more general issue - you decide...

I just can give you my 'user' perspective.

*** Bug 239133 has been marked as a duplicate of this bug. ***

I opened a similar defect last week which appears have been marked as a duplicate of this defect.


I understand that theres a potential performance risk involved when maintaining alot of "open" projects, but why not scan the child modules when performing a find usages?  Might be worth while when performing a find usages on a maven based project to have an additional selected scope that says "Include Child Projects?"

I would really like to see this make it into Netbeans 8, as this is the biggest area where netbeans falls behind the competition for me, and forces me to check for usages in eclipse(Child projects are automatically included, AFAIK) as I can not trust the results of a netbeans Find Usages search.

@Milos any word on this?

The only way I could work around this is by opening all maven projects (by checking the checkbox when opening the topmost parent project).
Refactoring now works without errors - however and pretty fast (except for the first time I open Find Usage or sth similar).

However from the usage point of view it's a big mess since, 95% of the projects I do not need to be open - other than for the NB specific technical reason, that they have to be open in order to Refactoring to work correctly...

Well - I got used to it, the same way you get used to a draft from a window or other annoyances... Well I am exaggerating :) - performance is still very good with around Xmx1700 and that's more important to me!

Thanx for keeping up the good work, guys - really! 
Have a blessed advent!

(In reply to satory from comment #20)
> I opened a similar defect last week which appears have been marked as a
> duplicate of this defect.
> 
> 
> I understand that theres a potential performance risk involved when
> maintaining alot of "open" projects, but why not scan the child modules when
> performing a find usages?  Might be worth while when performing a find
> usages on a maven based project to have an additional selected scope that
> says "Include Child Projects?"

That would need (API) changes on the side of refactoring/java support. And likely also API changes in project support in general as the OpenProjects.isOpened(Project) is used at quite a lot of places and would influence this as well. Then all places calling isOpened(Project) or getOpenedProjects() would have to be re-evaluated for semantics.

> 
> I would really like to see this make it into Netbeans 8, as this is the
> biggest area where netbeans falls behind the competition for me, and forces
> me to check for usages in eclipse(Child projects are automatically included,
> AFAIK) as I can not trust the results of a netbeans Find Usages search.
> 
> @Milos any word on this?

Not to be even considered for 8.0, it's quite a bit of work, across the whole IDE with potencial to disrupt existing functionality.

Since NB 8.1 you can do "Find usage with dependencies". 

http://wiki.netbeans.org/FindUsagesDependencies
https://netbeans.org/bugzilla/show_bug.cgi?id=55291

@Tomzi: Is this issue obsolete?