Bug 188323

Dev build. Opened karaf/shell/console from inside https://svn.apache.org/repos/asf/felix/trunk 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/Console.java remained:

method addCompletor in class jline.ConsoleReader cannot be applied to given types
  required: jline.Completor
  found: org.apache.felix.karaf.shell.console.jline.CompleterAsCompletor

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.

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.

(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.

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).

Created attachment 106460 [details]
Testcase for problem 1.

http://hg.netbeans.org/jet-main/rev/49d13ed75da4

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.

Integrated into 'main-golden', will be available in build *201103110400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/49d13ed75da4
User: Jan Lahoda <jlahoda@netbeans.org>
Log: #188323: ensuring that follow-up works are processed in the dependency order.

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: .
URL: http://svn.apache.org/repos/asf/maven/maven-3/trunk
Repository Root: http://svn.apache.org/repos/asf
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:
-J-Dorg.netbeans.modules.java.source.indexing.JavaCustomInxer.no.one.pass.compile.worker=true

(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?

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.

The patch seems good to me.

(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.

Transplanted to release70:
http://hg.netbeans.org/releases/rev/ab439f6ffbe0

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)