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.
Create a Maven quickstart project. Delete dep on junit; an error badge appears on Test Packages (and the project) as expected. Then delete src/test. The error badge remains on the project node even though Test Packages is gone. In Files, the project folder and src both have error badges, even though nothing beneath src has an error badge. I think I have seen a similar problem with NBM projects which set disable.qa-functional.tests=true - an error badge corresponding to broken functional tests persists even though test/qa-functional/src is no longer reported as a Java source group.
Try opening spi.debugger.ui for example. core-main #0106cbdb699b ameliorates the problem, since previously test/qa-functional/src was mistakenly registered in GlobalPathRegistry; now no error badge is shown when the project is opened. But if you browse to and open some source file under spi.debugger.ui/test/qa-functional/src, the error badge appears - and will reappear after restarting the IDE, even if you first close the file and collapse all nodes. java.source seems to be somehow remembering that there was once a file with an error underneath this directory, and refuses to forget. I don't know how to clear the badge except by deleting var/cache/index.
I think these are two independent usecases. For the second one (the NBM project), we may need some support from projects, I think. The problem is that even is the source root is not registered in the GPR, we are still required to scan it as soon as first file from it is opened (="opening file from unopened project"). After that the error really exists in the caches. Through the badging "API" then comes something like "${prj}/test". In the Java-only version, we looked at all the "java" source groups that belonged into ${prj}/test, but that does not work anymore, as we have generic version of this coloring. So now, we take the errors from all indexed source roots under the given folder, which in this case includes also the qa-functional tests. We may need a special source group "source-root" to find out about any-language source roots. The only alternative I see is looking at the things registered in GPR and deciding from that, but as queries are very slow (for NBM projects), I am not sure if this would work.
(In reply to comment #2) > We may > need a special source group "source-root" to find out about any-language source > roots. Or perhaps interface Sources2 extends Sources { Collection<String> sourceGroupTypes(); // not including _GENERIC } I am OK with the error badge appearing in the Files tab on the "test" folder (in the second case); it makes a certain amount of sense. The problem is with the error badge appearing on the project. The first case, an error badge appearing for a source root which has already been deleted, seems like a simple bug in the Indexing API or wherever this badge is implemented now.
Also note bug #174522 comment #8 - Maven archetype projects can contain Java sources intended to be copied but these are not in a declared source root and should not be scanned. (In some cases it might be possible to deduce a classpath for them from the pom.xml template, but they could also contain substitution tokens beyond the capacity of the Java parser.)
(In reply to comment #4) > Maven archetype projects can contain Java > sources intended to be copied but these are not in a declared source root and > should not be scanned. Currently irritating me due to https://svn.codehaus.org/mojo/trunk/mojo/mojo-archetypes/osgi-archetype/src/main/resources/archetype-resources/src/main/java/Activator.java (added today). Opening osgi-archetype even in a fresh user dir shows an error badge, so there is no workaround.
I have fixed the two original usecases: http://hg.netbeans.org/jet-main/rev/5da4a19ee7ac http://hg.netbeans.org/jet-main/rev/46dade38862a The lastest one related to Maven seems more like a problem in Maven itself: the source root is registered in GPR, and the corresponding ClassPath appears to include osgi-archetype/src/main/resources/archetype-resources/src/main/java/Activator.java (even though the corresponding SourceGroup does not contain it, which is inconsitent). So the java.source's and parsing.api's behavior seems correct. The only way to solve this in parsing.api would be to check project owner of each and every file while recognizing files (in addition to ClassPath.includes), but that is undesirable IMO because: -parsing.api is expected to work over the queries (as much as possible), not depending on Projects -would slow-down the indexing for everyone, even though cases like this are extremely rare If the given source root should not be indexed, Maven support should not register it in GPR. If it is, its source classpath should do includes/excludes correctly.
The Parsing API will not use the SourceGroup.contains as it will slow down the scanning. We are already using CP.Entry.includes()
OK, adjusting summary since I guess this is a separate bug.
Integrated into 'main-golden', will be available in build *201011190001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/5da4a19ee7ac User: Jan Lahoda <jlahoda@netbeans.org> Log: #189037: listen on create/delete events on non-source root folders and refresh icons/memory cache to ensure the error badges are correct
*** Bug 201349 has been marked as a duplicate of this bug. ***
core-main #87221d6a2de6
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/87221d6a2de6 User: Jesse Glick <jglick@netbeans.org> Log: #189037: src/main/resources/archetype-resources should not be indexed