Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 188323 - Incorrect error badges on Maven 3 sources
Incorrect error badges on Maven 3 sources
Product: java
Classification: Unclassified
Component: Source
PC Linux
: P2 (vote)
: 7.0
Assigned To: Jan Lahoda
Depends on: 190852 195928 196554
Blocks: 121950
  Show dependency treegraph
Reported: 2010-07-02 15:01 UTC by Jesse Glick
Modified: 2011-03-24 01:00 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT

Testcase for problem 1. (55.34 KB, application/zip)
2011-02-25 21:31 UTC, Jan Lahoda

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2010-07-02 15:01:58 UTC
Check out and open as a project group (...Required Projects). There are various error and warning badges, as expected. F11 to build, and then Resolve Problems on all projects which show the warning badge to download any other dependencies locally. There are still Java error badges on some projects, and they persist after a restart. Deleting $userdir/var/cache/index/ and restarting makes the badges all disappear, meaning that the Java indexer cache is to blame.
Comment 1 Jesse Glick 2010-10-06 21:21:27 UTC
Dev build. Opened karaf/shell/console from inside and saw a bunch of errors - to be expected, since most dependencies are not available yet. Did Build with Dependencies, which succeeds. Most of the errors disappeared, yet one on src/main/java/org/apache/felix/karaf/shell/console/jline/ remained:

method addCompletor in class jline.ConsoleReader cannot be applied to given types
  required: jline.Completor

Rewriting to

jline.Completor completor = new CompleterAsCompletor(...)

shows an "incompatible types" error. Jumping to the neighboring source for CompleterAsCompletor shows

import jline.Completor;
public class CompleterAsCompletor implements Completor {

with no error badges.

This same basic problem has happened for a long time (not a recent regression), and is very common when working with Maven projects. The Java parser tries to refresh after the dependencies become available, yet it still seems to cache some information about the type hierarchy which never gets corrected. The errors interfere with regular work, and restarting the IDE does not help, so there is no satisfactory workaround besides deleting the parser cache -> P2.
Comment 2 jmborer 2010-10-08 14:03:41 UTC
Moreover Maven 3.0 requires now that specify versions for all plugins even for already defined ones like compiler or jar. However NB reports a warning that we override the version number for the plugins where it shouldn't.
Comment 3 Jesse Glick 2010-10-08 16:18:00 UTC
(In reply to comment #2)
> NB reports a warning that we
> override the version number for the plugins where it shouldn't.

Nothing to do with this issue. If you find any bugs in the Maven support, please file them under projects/maven with complete steps to reproduce.
Comment 4 Jan Lahoda 2011-02-25 21:30:31 UTC
Aside from the two bugs linked in depends on, I have found two bugs in the java indexing:
1. order of rebuilding supplementary files: even though the JavaCustomIndexer sends supplementary roots to rebuild in the dependency order, due to absorbing of the works inside RepositoryUpdater, the files/roots may actually be rebuilt in wrong order, leading to wrong error badges. I will attach a test case, consisting of four projects. To reproduce:
-unpack, hg up -r 0
-start the IDE
-open all projects, wait for scan
-stop the IDE
-hg up -r 1
-start the IDE
2. (not 100% sure how this happens yet) consider three source roots (sr1, sr2, sr3). All of them are indexed, sr2 and sr3 contain some errors. During initial scan, the following happens:
-sr1 is parsed, contains a new class that fixes sr2, supplementary indexing is scheduled (but will happen after the initial scan finishes)
-sr2 is parsed, but does not have any direct changes (so the errors remain there)
-sr3 (depends on sr2) the source path for sr3 changes, the indexing may fix some error and introduces new ones (due to errors in sr2)
-supplementary indexing runs, sr2 is fixed, but sr3 is not reindexed anymore

I think I know how to fix 1., not yet sure about 2 (might be possible to merge the supplementary indexing of sr2 to its initial scan, but I did not succeed so far).
Comment 5 Jan Lahoda 2011-02-25 21:31:28 UTC
Created attachment 106460 [details]
Testcase for problem 1.
Comment 6 Jan Lahoda 2011-03-10 10:16:56 UTC
Comment 7 Jesse Glick 2011-03-10 15:04:39 UTC
There are still open bugs on related topics in the Maven component which are not going to be touched for 7.0; maybe for 7.0.1.
Comment 8 Quality Engineering 2011-03-11 09:41:53 UTC
Integrated into 'main-golden', will be available in build *201103110400* on (upload may still be in progress)
User: Jan Lahoda <>
Log: #188323: ensuring that follow-up works are processed in the dependency order.
Comment 9 Jan Lahoda 2011-03-11 11:54:01 UTC
The above fix and fixes for bug #196554 fix the known problems in java.source. I use steps similar to these:
-clean userdir, no $HOME/.m2, cleaned (i.e. not built) checkout of maven:
$ svn info
Path: .
Repository Root:
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1074467
Node Kind: directory
Schedule: normal
Last Changed Author: bentmann
Last Changed Rev: 1074306
Last Changed Date: 2011-02-24 22:31:36 +0100 (Thu, 24 Feb 2011)
-start the IDE, open the checkout, and open all its modules
-wait until scan is finished, build the main project
-after that, click on each project and resolve problems (not very user-friendly, BTW)
-there are still many projects with errors (I believe this is at least partially caused by the maven support reporting wrong source path)
-restart the IDE, wait until the scan finishes
-there shouldn't be any error badges in any of the projects

Would be good to test both with and without:
Comment 10 Jesse Glick 2011-03-11 15:42:29 UTC
(In reply to comment #9)
> click on each project and resolve problems (not very user-friendly, BTW)

No, it's not. Bug #189442

> maven support reporting wrong source path

Bug #190852 you mean?
Comment 11 Jaromir Uhrik 2011-03-15 09:17:27 UTC
I have tested the fix in the trunk build number 201103140400 (Ubuntu, Jdk6u24). I agree with integration of the fix to NB7.0. Honzo, please integrate if there is no objection from Jesse. Thanks

Verified in the trunk.
Comment 12 Tomas Zezula 2011-03-15 16:38:18 UTC
The patch seems good to me.
Comment 13 Jesse Glick 2011-03-15 22:43:04 UTC
(In reply to comment #11)
> please integrate if there is no objection from Jesse

I do not know enough about the patch to either approve of it or object to it.
Comment 14 Jan Lahoda 2011-03-17 09:25:39 UTC
Transplanted to release70:
Comment 15 Jaromir Uhrik 2011-03-24 01:00:45 UTC
Verified in the following 70 build:
Product Version: NetBeans IDE 7.0 RC1 (Build 201103230000)
Java: 1.6.0_24; Java HotSpot(TM) Client VM 19.1-b02
System: Linux version 2.6.35-22-generic running on i386; UTF-8; en_US (nb)

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo