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.
I have been advised to file separate issues for the same set of errors found in bug 235622 which is currently reserved for the JPQL side of it only. Please refer to description and log files attached to bug 235622. I assign this a priority 1 because for me a little refactoring is always a litmus test whether I can use a new release and I have to say this test failed very badly. The first attempt with a build 1 week older produced OutOfMemoryError which sadly I failed to report. Then with the same procedure I got these errors where the IDE took 60 minutes to recover from. Better than before, but still 60 minutes of no response from the IDE. Interestingly, the refactoring was very quick for each change but suddenly error badges appeared on a large number of files.
Changing to P4 since the original issue appears to be fixed. I would be interested to know how to verify a situation described in bug 193190 "sometimes, Coupling errors are thrown for valid reason - e.g. if there is a jar file with attached sources, however the sources does not match the jar file content (sometimes happen when e.g. there is an rt.jar with src.zip attached the comes from different JDK version)." The .sig_99.dump files are application source files with stack traces in them not source files from libraries. So it looks like application files get corrupted with refactoring after the cache was cleaned entirely. I would like to know what I could do to help here, whether this may still be caused by library source file / jar file inconsistency even if the dump files are application files. Is there an easy way to check consistency between source and class files programmatically?
I have a kind of a test case. I could not make a clean one that I can attach. But it reproduces always. Errors in the log file are like: VARIABLE: x0 Coupling error: class file: file:/C:/.... I have reduced the project to 108 java files so it it no longer large. The files where the coupling errors occur are always the same. If I make small changes to these files, or even if I make changes to other files, then the error vanishes, so I cannot make a smaller test case at this stage.
There is an easy way to reproduce this as follows: Start NetBeans in new userdir without importing settings Menu|Tools|Options|Files|Uncheck Enable auto-scanning of sources Menu|Team|Git|Clone https://github.com/apache/wicket.git select build/wicket/6.10.0 When presented with dialog, open project wicket-examples resolve dependencies In log, many entries like: INFO [org.netbeans.api.java.source.ElementHandle]: Cannot resolve: ElementHandle[kind=OTHER; sigs=org.apache.wicket.examples.repeater.PagingPage$1$1 ] WARNING [org.netbeans.modules.j2ee.metadata.model.api.support.annotation.PersistentObjectManager]: typesAdded: type ElementHandle[kind=OTHER; sigs=org.apache.wicket.examples.repeater.PagingPage$1$1 ] has dissapeared So it looks like it could be an issue with inner classes, but the main issue comes later. Then there is a build error: Failed to execute goal org.apache.maven.plugins:maven-war-plugin:2.2:war (default-war) on project wicket-examples: Could not copy webapp classes [C:\bt\java\servlet\Wicket\source-6\wicket\wicket-examples\target\classes]: File C:\bt\java\servlet\Wicket\source-6\wicket\wicket-examples\target\classes\org\apache\wicket\examples\echo\EchoApplication.class does not exist -> [Help 1] Different issue, the file exists, we are only interested in sources ... Do some refactoring: Rename WicketExamplePage.java to WicketExamplePage1.java In log file, there are entries: Coupling error: class file: file:/C:/bt/java/servlet/Wicket/source-6/userdir/var/cache/index/s76/java/14/classes/org/apache/wicket/examples/compref/CheckBoxSelectorPage.sig source file: file:/C:/bt/java/servlet/Wicket/source-6/wicket/wicket-examples/src/main/java/org/apache/wicket/examples/compref/CheckBoxSelectorPage.java VARIABLE: x1 Please see attached log directory.
Created attachment 140073 [details] log directory in zip file This reproduced the first time with refactor rename. It reproduces the same way as in my own project. Product Version: NetBeans IDE Dev (Build 201309110001) Updates: Updates available Java: 1.7.0_25; Java HotSpot(TM) Client VM 23.25-b01 Runtime: Java(TM) SE Runtime Environment 1.7.0_25-b17 System: Windows XP version 5.1 running on x86; Cp1252; en_NZ (nb) Computer: Lenovo MT-M 6072-ADM Intel E6550 dual core 2.33GHz CPU 4MB L2 cache 3GB of DDR2 667MHz RAM 250GB SATA II harddrive
*** Bug 188808 has been marked as a duplicate of this bug. ***
Is this related? Issue 232587
The 'cannot resolve' seems to come from files scanned during the priming build, which reference types that have not been built yet. Does not IMHO indicate an issue. Other than that, no error appeared in the IDE log :-/ no coupling errors. I've started from the scratch (freshly installed freshly built fresh dev checkout), and I suspect that my local mvn repo did not contain wicket artifacts at all (which may make ?).