I have xml schema that is generated by maven using maven-jaxb-plugin. When I have deleted target directory and open
project in java files, which uses resources from generated classes, exclamation marks appear. After building project,
generated sources are created, but exclamation marks still appears. I can reopen project, and then exclamation mark
disappear, but when I click reload project it doesn't. I can also open all files with exclamation mark, and then
exclamation marks also disappear.
I have installed all available updates.
Product Version: NetBeans IDE 6.0 (Build 200711261600)
Java: 1.6.0; Java HotSpot(TM) Client VM 1.6.0-b105
System: Windows XP version 5.1 running on x86; Cp1250; pl_PL (nb)
Userdir: C:\Documents and Settings\faramir\.netbeans\6.0
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
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.
"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:
(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
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:
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
User: Jan Lahoda <email@example.com>
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
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
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):
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:
Integrated into 'main-golden', available in NB_Trunk_Production #221 build
User: Jan Lahoda <firstname.lastname@example.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/
I've tested it now. It works almost good, but one little bug stay - source packages are [re-]compiling, but test
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
thanks for info, I'm marking it as verified then
The fix has been ported into the release61_fixes branch:
*** Issue 134275 has been marked as a duplicate of this issue. ***
*** Issue 135146 has been marked as a duplicate of this issue. ***