Add support for clearing NB cache for certain project and scan it again

[PavelTurk]

Description

Unfortunately it is very often when NB doesn't see serious changes in code. For example, there is a Project A that depends on Project B. Project A is compiled without any errors and NB shows no error in the project and its packages.

Now, we do serious changes in Project B and compile it. NB shows errors in Project A, although Project A is again compiled without any errors.

Restarting NB doesn't help. The only solution is to clear NB cache. If there is another ways, please tell me, but I didn't find. That's why I suggest to add functionality that will clear NB cache for certain project and make NB scan this project again.

Use case/motivation

No response

Related issues

No response

Are you willing to submit a pull request?

No

[Chris2011]

What was the reason to close it @PavelTurk? Did you find a solution, if yes, what is the solution to let everyone knows.

[PavelTurk]

@Chris2011 Thank you for you comment. Right click on project -> Reload helped me once. But I am not sure that this is a valid solution for serious cases. For now I decided to close this issue and wait till next problem.

[PavelTurk]

@Chris2011 I reopen this issue. Reload doesn't help. For example I have the following error:

Project is compiled without any problems, everything works as expected, all tests passed, gson dependency 100 times checked. But I constantly see this error which marks whole subproject as having error.

[Chris2011]

What does the lightbulb says if you click or hover on it?

[PavelTurk]

@Chris2011 It says: package com.google.gson is not visible (package com.google.gson is declared in module com.google.gson but module my.module does not read it). But it is not true:

module my.module {
...
requires com.google.gson;
...
}

I've noticed that sometimes this error disappears but later it appears again. It seems that NB doesn't like this module :)

[Chris2011]

Can you please make a little reprodiucable project and share it with us? we don't know whether it is ant or maven or gradle or whatever. Also please use the default issue template and don't remove the needed information. Which NetBeans version do you use? Which operating system etc. We are good but we are not wizards to know what your environment is.

[PavelTurk]

No, this issue must be resolved. I am working now with NB 22:

Product Version: Apache NetBeans IDE 22
Java: 22.0.1; OpenJDK 64-Bit Server VM 22.0.1+8-16
Runtime: OpenJDK Runtime Environment 22.0.1+8-16
System: Linux version 5.15.0-88-generic running on amd64; UTF-8; en_US (nb)

Again, after serious refactoring I have many errors on Projects tab, at the same time all projects are built without any problems. I tried:

1. Project -> right click -> reload pom.
2. Main menu -> Source -> Scan for External Changes.

It didn't help. At the same time this problem is not reproducible because it is related to cache. As I understand if there is a lot of code and you refactor heavily used code, then NB makes errors and stops working properly. The only solution that I constantly use is

1. Close NB
2. Delete NB cache
3. Start NB.

I don't think it is a normal solution.

[matthiasblaesing]

No, this issue must be resolved.

Just for the record: Stating the obvious won't help resolving it. The people here improve NetBeans and fix problems and I can only speak for me, that I focus on things that are reproducible and relate to my problems. I guess the same is true for others.

I also so invalid cache states (primarily on Windows) where sources generated by javac annotation processing were not picked up until I modified the source file the generated code was based on, but then same problem: Without a reproducer I can bitch about it, but it won't get fixed faster.

[PavelTurk]

@matthiasblaesing I don't know what you mean by Just for the record: Stating the obvious won't help resolving it. . When I said No, this issue must be resolved. I meant that I was thinking about this issue and now I am sure, that this issue should be resolved. Maybe I have problems with English as it is not my native language but I didn't mean anything more.

[Chris2011]

@PavelTurk But the obvious is here, yes every bug of problem should be fixed, but we need to identify and reproduce the problem. If we can't, we can't do anything. Atm you are maybe the only one (probably not) that can reproduce the problem. And again, if you have a project to share with us to test it, it would be good. Also we need to know what you mean by heavily refactoring. What exactly did you do Step by step.

[PavelTurk]

@Chris2011 I am working on private commercial projects, so I can't share them. Besides it would require to share my cache - I don't know if it would help, but who knows. So, I can't provide test code to reproduce the bug.

Saying refactor heavily used code I mean the following. Consider my situation:

project A
 - jpms module API
 + 2 jpms modules

project B (5 jpms modules and they use API module from project A)
project C (8 jpms modules and they use API module from project A).

Now I need to refactor some interfaces in API module of project A. For example to split one interface into two. The probability that I will have to clear the cache again after such a refactoring is very high.

So, I see the following variants:

1. This issue is closed and forgotten.
2. Provide any tools in NB that I could use to detect bug. Because IDE log doesn't show any errors.
3. This issue is resolved as NO test code IS REQUIRED to do it. Because this issue is about a new feature, for example project -> right click -> rebuild cache. The same task is executed when NB starts after installation or on the first opening the project.

I vote for variant 3. Reasons are the following:

• other users also clear their cache
• NB is a great IDE but it seems that errors in cache are very difficult to fix.
• The following question was viewed 277K times - https://stackoverflow.com/questions/8689780/how-to-clear-the-cache-in-netbeans

[neilcsmith-net]

I agree that both a general clear cache, and a rebuild code caches for a project, would be useful. So would ensuring all aspects of Java parsing are module aware. I'm working on a large JPMS project with about 20 sub-projects at the moment, and see these sort of errors a lot.

Out of interest, does editing and saving the module-info file clear errors for you?

If you open projects in the order that they are depended on, do you see less errors?

Are there dependencies that are automatic modules? You mention GSON earlier, which I think is? Have you opened the code for any of these? One problem I definitely see is automatic modules having different resolved module names in this case.

I've started debugging through some of these in the past, and will take another look when time allows. At the moment, I'm stuck applying similar workarounds for the work I'm doing.

[Chris2011]

The clear cache button or rebuild I like too, but the thing is also why this happens anyway? I mean this is just a workaround for the root problem. My 2 cents,

[neilcsmith-net]

@Chris2011 sure! Most of my comment was about the root cause(s). There are one or more bugs around parsing with JPMS. Certainly the code to compute module names is fragile, but I think there are other issues at play too. Ideally they'll get fixed. There are a variety of other issues where clearing the cache on a project or global basis is the workaround. Making the workarounds easier to use doesn't imply that the root causes don't need addressing.

[PavelTurk]

@neilcsmith-net

Out of interest, does editing and saving the module-info file clear errors for you?

Yes, it helps for tests. I tried several times and it helped.

If you open projects in the order that they are depended on, do you see less errors?

No, I didn't notice any difference.

Are there dependencies that are automatic modules? You mention GSON earlier, which I think is? Have you opened the code for any of these? One problem I definitely see is automatic modules having different resolved module names in this case.

It seems that I have problems with all types. Many times I had assertj imports red, at the same time assertj has module-info:

but at least with tests I can use your hack about editing module-info. Thank you.

[matthiasblaesing]

Here is a quick and dirty, untested plugin to force a rescan: https://github.com/matthiasblaesing/netbeans-project-rescan

It determines the roots for the project directory, then destroys the index/cache for these and issues a rescan. This is untested and each uses kills a cute kitten, but maybe it helps.

[PavelTurk]

@matthiasblaesing Thank you very much. I've started testing your plugin today. When I have results I will share them.

[PavelTurk]

@matthiasblaesing I tested your plugin several times and it seems to work. Earlier I edited module-info to remove all errors, but now I do right click -> Rescan project (maybe it should be Rescan Project) and the problem is solved.

[Chris2011]

I also using it. Thx for that.