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.
Summary: | classpath/sourcepath doesn't update after reload | ||
---|---|---|---|
Product: | java | Reporter: | faramir2 <faramir2> |
Component: | Source | Assignee: | Jan Lahoda <jlahoda> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | jbecicka, jiriprox, kawazu428, mkleint, sustaining, tzezula |
Priority: | P2 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
A (source) patch against release61
A binary patch against release61 |
Description
faramir2
2008-02-25 15:56:57 UTC
Classpath module represents just an API, SPI bridge. Project module is responsible for correct firing and so on. tzezula: faramir2 said "I can also open all files with exclamation mark, and then exclamation marks also disappear." The fact that the exclamation mark disappears on java file opening, suggests this is not a problem of project firing changes. mkleint: No. This is the behavior when the IDE didn't got an event about source root recreation and children recreation. When you open the file the compiler completes the closure using java.io.File. The files are marked by error until open because the RepoUpdater doesn't know about the change. issue 126259 is very related, most probably a duplicate. quote: "Secondly, if I edit the pom.xml file and remove a dependency, it disappears from the Libraries list in the Project view. Any code that relies on that dependency shows errors in the editor window (and is marked in the Project view with an exclamation mark in a red circle). However, when I add that same dependency back in exactly as it was (again, by editing the pom.xml), although it reappears in the Libraries list, the files that depend on it still show errors, both in the project view and in their respective editor windows." that's the same behaviour we experiencing here, the project filres changes correctly but going from "error marks->no error marks" state seems to be unreliable. *** Issue 128325 has been marked as a duplicate of this issue. *** *** Issue 129056 has been marked as a duplicate of this issue. *** *** Issue 126259 has been marked as a duplicate of this issue. *** multiple duplicates, increasing priority ->P2 possibly duplicate of #129916 that is about to be fixed. Need to verify it's actually a duplicate.. yes, duplicate of #129916. I could not reproduce anymore in a build that includes fix for #129916 *** This issue has been marked as a duplicate of 129916 *** thanks mkleint, but how to I can use this fix? If it's possible without downloading sources and compiling or I must wait for new update pack? that owuld be a daily build of netbeans 6.1 from here for example: http://deadlock.netbeans.org/hudson/job/trunk/lastSuccessfulBuild/artifact/nbbuild/dist/zip/ (please note that it's not included in the released beta of 6.1) Is there a workaround for this issue that I could apply to Netbeans 6.0.1? I saw the same state in NetBeans 6.1 RC1. Red exclamation mark appear, but clicking "reload project" doesn't recheck classpath. Only after a long while (or when opening file with that mark) classpath is read again and exclamation mark disappear. I think that code complementation is connected with this issue: after adding methods in generated sources, after pressing CTRL+SPACE new methods aren't visible. Honzo, can you look a it please? I can sporadically reproduce in the sample scenarios of commenting out junit dependency in pom.xml and reinserting it later. once in a while the markers don't get updated. My investigation shows that the change of classpath (in the case of Maven project and adding/removing dependency on JUnit) is correctly fired and forces rescan of the corresponding source root. In some cases, the scanning is interrupted (which is fine), but is not resumed as it should be. I made the scan non-interruptible (as it was in NB6.0) for now: http://hg.netbeans.org/main/rev/ad556cb5835b After thinking about it more, I am not sure if the scan should be interruptible in this case - keeping this issue open for now to decide (and implement) the (non-)interruptibility of this part of the scan. Integrated into 'main-golden', available in NB_Trunk_Production #206 build Changeset: http://hg.netbeans.org/main/rev/ad556cb5835b User: Jan Lahoda <jlahoda@netbeans.org> Log: Temporary fix for #128326 - making the parseFiles invoked from updateFolder non-cancelable, as it originally was. This issue needs to be closed, so it can be considered as a candidate for a patch release. I have filled issue #135415 for the cancelability concerns (please feel free to add yourself on CC). The patch from trunk cannot be applied to release61 - I will attach a patch against release61 shortly. I am going to attach two patches: -a source patch against release61 -a binary patch against release61. To install it, put the 128326.jar into directory ${NETBEANS_INSTALL_DIR}/java2/modules/patches/org-netbeans-modules-java-source (${NETBEANS_INSTALL_DIR}/java2/modules/ should exist, patches/org-netbeans-modules-java-source will need to be created). It would be great if the people experiencing the problems could test the patch. To remove the patch, it is enough to delete the 128326.jar from the above directory. Thanks. Created attachment 61630 [details]
A (source) patch against release61
Created attachment 61631 [details]
A binary patch against release61
I copied .jar file as you said, but I still see misfunction. Maybe I cannot describe it good enought? :( I tried to record what's wrong and here you can download video (about 11 MB, 11min): http://www.mat.umk.pl/~faramir/nb-xvid.avi I hope that help you to fix it (or explain that, this is feature not a bug :P). faramir2: seems that there was another problem related to the generated sources (the src/main/java and the generated source root are considered to be one compilation unit), should be fixed by this commit: http://hg.netbeans.org/main?cmd=changeset;node=7aa22484bff8 Integrated into 'main-golden', available in NB_Trunk_Production #221 build Changeset: http://hg.netbeans.org/main/rev/7aa22484bff8 User: Jan Lahoda <jlahoda@netbeans.org> Log: #128326 continued: the same instance of ClassPath may be provided used by more than one source root. *** Issue 135881 has been marked as a duplicate of this issue. *** faramir2: can you please verify the fix, we will be able then to include it in to patch2. The dev builds can be downloaded here: http://deadlock.netbeans.org/hudson/job/trunk/ Thanks I've tested it now. It works almost good, but one little bug stay - source packages are [re-]compiling, but test packages aren't. To see more please watch: http://www.mat.umk.pl/~faramir/nb2-xvid.avi (11 MB) Quality is very low, but I hope that you see what is wrong. Not quite sure what is wrong there - might be the fact that changes in one source root won't cause recompile in other source roots (issue #125870). More info on how to reproduce the problem would be helpful. Anyway, if I understand it correctly, the above patches help, and the patches cannot be incorporated in the patch2 unless the issue is in verified state. So, unless someone disagrees, I propose to create a new issue to cover the new problem and change status of this one to verified. Jirka, could you please take care of this? Thanks. Recompiling "Test source package" is wrong only (doesn't recompile it). "Source package" is working correctly. If bug in "test source package" isn't so bad, I can say, that this issue can become VERIFIED. Recompiling "Test source package" is wrong only (doesn't recompile it). "Source package" is working correctly. If bug in "test source package" isn't so bad, I can say, that this issue can become VERIFIED. thanks for info, I'm marking it as verified then The fix has been ported into the release61_fixes branch: http://hg.netbeans.org/release61_fixes/f99dba0ee5d2 *** Issue 134275 has been marked as a duplicate of this issue. *** *** Issue 135146 has been marked as a duplicate of this issue. *** |