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.
[dev-200502061900, JDK 1.5.0_02] I created very simple j2se project with three packages with one main class in each package. I expanded all package nodes in Explorer and was doing compilation of selected files (in editor or in Explorer) or (clean) build of entire project and compile status badging of those files in Explorer didn't reflect reality, it was basically random.
It is probably regression caused by fix of issue 53237. Honzo, can you take a look at it?
I do not think it relates to issue #53237. IMO it is a bug of the ant/project. I have added logging for GlobFileBuiltQuery and it seems that JavaNode icon is in sync with the GlobFileBuiltQuery.Status. GFBQS simply does not fire changes reliably.
Tomas, please look at this. Milan, if you think this is a regression. Do you have any idea when (approximately) it could occur? Does it work correctly in NB 4.0?
I will check that.
Problem appeared in build 200501092025.
Radek, IIRC you integrated the new masterfs around that time (Jan 9). Could it be related? I'm not saying it is, just guessing -- perhaps, some events not fired from the filesystem...?
See: #53203: GlobFileBuiltQueryTest.testChangeFiring is failing. This issue was opened and fixed 2005-01-11. Marked as duplicate of #53203. If someone can reproduce on current builds please reopen. I'm not. *** This issue has been marked as a duplicate of 53203 ***
I've spent some time debugging it and it seems that the FileChangeSupport listens on "classes" folder but it does not get an event from it. The listener was added in the FileChangeSupport.locateCurrent () and was not removed either in FileChangeSupport.locateCurrent () or in FileChangeSupport.run () Seems a bug in FileSystems.
This issue was reported on Feb 11, so unless I'm missing something, it can hardly be a duplicate of bug that was fixed on Jan 11. Also, Tomas' evaluation suggests that the problem still exists. Re-assigning to filesystems.
Sorry, not working for me in dev-200502151900. Probably different issue, see Tomas's last comment.
I saw dev-200502151900 and didn't notice [dev-200502061900]. When it was reported is more or less unimportant because even today are sometimes filled issues against NB3.5 or 3.6. Definitely sorry.
Agree with Radek, that this feature is not so important. I personally would remove it at all. I am not sure if it is P2, probalbly P3 is enough.
First of all it's major regression and the functionality is highly visible in the Explorer and it looks really bad if it shows those badges randomly. Please keep it as P2.
Fixed in trunk. org/netbeans/modules/masterfs/filebasedfs/children/ChildrenSupport.java?r1=1.4&r2=1.5 org/netbeans/modules/masterfs/filebasedfs/fileobjects/BaseFileObj.java.diff?r1=1.7&r2=1.8 org/netbeans/modules/masterfs/filebasedfs/fileobjects/FileObj.java.diff?r1=1.3&r2=1.4 org/netbeans/modules/masterfs/filebasedfs/fileobjects/FolderObj.java.diff?r1=1.2&r2=1.3
Verified in dev-200502231900.
*** Issue 55584 has been marked as a duplicate of this issue. ***
*** Issue 55806 has been marked as a duplicate of this issue. ***
Still reproducible in dev-200503061900.
Found by NetCAT participant.
OK, but WORKSFORME. Then please provide steps how to reproduce.
Steps to reproduce: 1) Open J2SEProject with java sources 2) Expand packages nodes with sources 3) Select some java source file and click Compile File in its context menu - maybe will work, maybe not 4) Select another java source file node and do the same 5) Do the same action on package node - Compile Package 6) Do Clean build for the project 7) Repeat any of 3) 4) 5) and 6) Compile statuses are random.
Justification for P2: - it's regression - it's highly visible feature of source nodes in Explorer - users relly on those badges to verify that file (project) is compiled
/cvs/ant/project/src/org/netbeans/modules/project/ant/FileChangeSupport.java new revision: 1.3; previous revision: 1.2
Uh, this looks like a very important fix, yet the actual source code change (in FileChangeSupport.java) is just one line whose purpose is far from obvious (not even any comment in this issue explaining it). Where is the unit test demonstrating the bug and confirming that the fix works??
I thought the line is more then obvious. FileChangeListeners used to be ever notified about children (add, remove) just in case that getChildren were called and internal cache was initialized (this is used in all filesystems tests). The only difference between NB4.1 and 4.0 is that AbstractFileObject.getFileObject internally called getChildren and thus cache was completely initialized and events were fired even if you required just one child.
Verified in dev-200503141900.
Back again. Reproducible in dev-200503221900. 1) Open attached project 2) Do Clean Project 3) Compile Package on <default package> 4) Compile Package on newpackage 5) Do Clean Project 6) Do Build Project And any combination of 2) - 6) Compile status is out of sync. Would be possible to write the unit test that Jesse mentioned. Justification for P2: - it's regression - it's highly visible feature of source nodes in Explorer - users rely on those badges to verify that file (project) is compiled
Created attachment 21049 [details] zipped test project
Created attachment 21051 [details] another test project
I've attached another test project that contains multiple source roots, where compile status badging are not reliable as well.
Regression caused by #56285.
/cvs/openide/masterfs/src/org/netbeans/modules/masterfs/MasterFileObject.java,v new revision: 1.40; previous revision: 1.39
Seems to be reliable again in build dev-200503242007. Verified.