Community
Participate
Working Groups
If I use copy/paste on a file, the new file will not be shown in the Package Explorer unless I close and reopen the project. Nor will it be shown in the "Java Browsing", it will - though - be shown in the Navigator (resource perspective). I'm currently running 3M8 Build id: 200403261517 on W2k Funny thing though, the "team" part flags the package as being dirty, i.e. the ">" is prepended to the package in the package explorer. Kind regards
Please double-check that you don't have any working set or other filtering enabled in those views that would conceal the file.
My only filters are: + Empty parent packages + Import declarations + Inner class files + Package declarations I don't tamper with the filters - and the funny part is still, the file becomes visible once the project has been closed and then re-opened - which IMHO should retain the same set of filters. If I create a new file, then it's visible. It's only the copy/paste thing and only in Java related perspectives. kind regards
Two questions: - do you have anything in the log ? - which build are you using ? And the most important one: do you have reproducable steps. I tried some simple copy/paste actions and they work for me.
I have nothing in the log. My Eclipse build is (as stated above) 3M8 Build id: 200403261517 I've tried to track the bug some more: In most projects I have, copy/paste works fine, unless the project has been closed for a while, then opened and contains a "src"-folder for the packages. Some projects without a "src"-folder, that has been closed, then re-opened, to check copy paste, works fine. Open projects, that has not - as far as I remember - been closed yet contains a "src"-folder works fine with copy/paste. Could it be an upgrade problem? Closed projects while upgrading from 3M7 to 3M8? Or possibly a problem with project closing? Or a mismatch during the upgrade? kind regards
Then when I finally get the files to show due to a project close/re-open, they don't disappear when I delete them - unless of course I close/re-open the project again. I'm just becoming more and more puzzled, perhaps I should just stay away from the Package Explorer. kind regards
Philippe, can you please comment on this. Since the package explorer updates in "normal" cases either the delta is a different one and the packages explorer misses it or the model doesn't sent the delta.
*** Bug 56872 has been marked as a duplicate of this bug. ***
Philippe ...
Hi, I have the same problem with Eclipse 3.0 M8 200403261517 on W2K SP3 (german) For example I create a java file in Windows Explorer in package aa.bb.cc (which is open in Eclipse in Package Explorer and already contains some files showed in Package Explorer) then I switch to Eclipse and make "Refresh" on the project and the file is not shown (this always worked in Eclipse 2.x) I have to close the project and reopen it and then it was shown. If the file has compiler errors the error marker is shown on the project so that the file is correctly read at refresh but not shown. I don't use filters. Regards, Cristian
Christian, I tried to reproduce the problem using 200404281424, but wasn't able to do so. Do you have more detailed steps than the once you provided ?
Hi Dirk, this is strange... I tried now for 2 hours to reproduce the bug but it worked every time! I didn't change anything in the settings or filters. Should I turn on Eclipse logging? I try to find a way to reproduce it! Regards, Cristian
I found it. It has something to do with read-only files not managed by the repository systems or read-only file for which we don't change the content.
Fixed for M9
I've just checked, the problem persist in 3M9 build: 200405211200 With a closed project. - open project - copy & paste file - copy of file is not shown - close project - open project - .. file is now shown (with a "?" on the "J"-icon (Java file) - 'not in repository', and prepended ">" showing modification) - delete file - .. file still exists in Package Explorer, yet has removed the modification flag ">", the "J"-icon now exists without further adornments - open file : "Cannot open default editor on <filename>. The file does not exist." - close project - open project - .. file is gone. Kind regards
I can't reproduce this under M9, so some help here is highly appreciated. I would really like to understand this bug and track it down. Some questions: - under which version control system is the project ? (CVS, ClearCase, ...). - are the files you are coping read-only ? - how does the layout of the project look like: ? src - package - onto which target do you paste the file - from where do you copy the file. Would it be possible for you to zip your workspace and attach it to the PR. This would be the easiest way to find out what is going on if you can provide steps how to reproduce this in our workspace. For the case that this is not possible (which I think will be very likely ;-)) I will attach an .options file to the PR. Can you please put the .options file into your eclipse installation and start eclipse with the following additional arguments: -debug -vm C:\jdk\bin\java.exe where the -vm points to a java installation on your system. This enables some tracing options which will be printed to the Java console. So you should set the buffer for this console to at least 2048 lines to catch enough information. If you reproduced the bug can you please attach the debug output. This will allow us to understand what was going on. Thanks for all your help to solve the problem.
Created attachment 11074 [details] The option file
This could be a duplicate of bug 62232. Per, when the problem happens in your workspace can you please try the following: if more than one compilation unit (Java file) is contained in the target package of the copy operation can you please select each compilation unit in the package and check if the name printed in the status line is the same as the selected file name. If not than this seems to be a JFace viewer refresh problem as well.
Hi, I'll try to answer as much as I can now - while I'm at home running Windows XP Pro and Eclipse 3M9 build 200405211200. I've just tested how I could possibly reproduce the bug. At first it didn't work. I checked out the project, closed it, opened, copied a file, and it showed .. then I thought: Maybe if the project was closed, when Eclipse was started, and now I can reproduce the bug. To answer some of your questions: - under which version control system is the project ? (CVS, ClearCase, ...). CVS running on a remote Linux or BSD server using "pserver" - are the files you are coping read-only ? No. - how does the layout of the project look like: ? src - package Yes, Project / src / package - onto which target do you paste the file I right-click on the package (in the Package Explorer), into which I want to paste the file, select "paste from the menu" and any filename - "CopyOf..." will do nicely - from where do you copy the file. I right-click on the file from the package (in the Package Explorer), selects "Copy" from the menu. I cannot zip the actual project, but it seems it's not needed. I've tested this: - create a new Java Project. - add a "src" folder. - create a package , e.g. dk.certus.eclipse - create a java file, e.g. interface Dummy - close the project. - close Eclipse - open Eclipse - open project - do the copy/paste .. no new file will show - close project, reopen it - there's the file - delete file .. it's still there - close project, reopen it - file's gone. I have the ".options" debug output if you still need it, though I think you'll be able to reporduce the bug. kind regards
Created attachment 11099 [details] Testrun with the .option file on a new workspace. I tested my discovery of closed project when Eclipse starts, as the debug writes the headers of my projects - which are of no interest - I copied the workspace, removed all but the CopyTest project and tested again - couldn't reproduce the bug. Then I created a new project: Test2 - exactly the same setup as CopyTest. I closed Test2, closed and started Eclipse - hence the dual "Install location:" in the debug. After a restart of Eclipse the mystery was back, I could reproduce the bug. /lauge
Created attachment 11119 [details] Zipped workspace with dummy code This is the actual projects I used for the debug data. I'm not allowed to zip the complete workspace as it's too large 2Mb, but I've tested this. Create a new workspace, import "existing project" CopyTest, import "existing project" Test2, close project Test2. Shutdown Eclipse. Open Eclipse on this workspace. Open project Test2, copy the single file "Dummy.java" and watch the bug in action. Kind regards
Hi Lauge, thanks for all the work you put in to reproduce the bug. The delta you attached is indeed really helpful. After trying for a while I was able to reproduce it. It is important to have the second project. It worked for me using the following steps: New workspace: - create project CopyTest with source folder src - create package dk.certus.eclipse - create interface Dummy - close project - close Eclipse - reopen Eclipse - reopen Project - expand CopyTest down to package - select Dummy - Copy - select package - Paste observe: file shows up - create project Test2 with src folder - create package dk.certus.eclipse - create interface Dummy - close Project Test2 - close Eclipse - open Eclipse - open project Test2 - expand to package dk.certus.eclipse - select Dummy - execute Copy - select package dk.certus.eclipse - paste observe: Package is missing copied file. I had logging enabled and I got the same trace already attached to the PR. The problem is that we receive different deltas in the cases where the copy works and in cases where the copy fails: When the copy works well the delta is as follows: MERGING 3 DELTAS [Thread[main,6,main]] Java Model[*]: {CHILDREN} CopyTest[*]: {CHILDREN} src[*]: {CHILDREN} dk.certus.eclipse[*]: {CHILDREN} [Working copy] Dummy.java[+]: {} Java Model[*]: {CHILDREN} CopyTest[*]: {CHILDREN} src[*]: {CHILDREN} dk.certus.eclipse[*]: {CHILDREN} [Working copy] Dummy.java[-]: {} Java Model[*]: {CHILDREN} CopyTest[*]: {CHILDREN} src[*]: {CHILDREN} dk.certus.eclipse[*]: {CHILDREN} CopyOfDummy.java[+]: {} FIRING POST_CHANGE Delta [Thread[main,6,main]]: Java Model[*]: {CHILDREN} CopyTest[*]: {CHILDREN} src[*]: {CHILDREN} dk.certus.eclipse[*]: {CHILDREN} CopyOfDummy.java[+]: {} Listener #1=org.eclipse.jdt.internal.corext.util.AllTypesCache$TypeCacheDeltaListener@98 f352 -> 0ms Listener #2=org.eclipse.jdt.internal.ui.packageview.PackageExplorerContentProvider@1bb86 94 -> 0ms Listener #3=org.eclipse.jdt.internal.corext.refactoring.changes.WorkspaceTracker$JavaMod elListener@857066 -> 0ms FIRING POST_RECONCILE Delta [Thread[main,6,main]]: <NONE> When the copy fails the delta looks like this MERGING 3 DELTAS [Thread[main,6,main]] Java Model[*]: {CHILDREN} Test2[*]: {CHILDREN} src[*]: {CHILDREN} dk.certus.eclipse[*]: {CHILDREN} [Working copy] Dummy.java[+]: {} Java Model[*]: {CHILDREN} Test2[*]: {CHILDREN} src[*]: {CHILDREN} dk.certus.eclipse[*]: {CHILDREN} [Working copy] Dummy.java[-]: {} Java Model[*]: {CHILDREN} Test2[*]: {CONTENT} ResourceDelta(/Test2/src)[*] FIRING POST_CHANGE Delta [Thread[main,6,main]]: Java Model[*]: {CHILDREN} Test2[*]: {CHILDREN} src[*]: {CHILDREN} dk.certus.eclipse[*]: {CHILDREN} ResourceDelta(/Test2/src)[*] Listener #1=org.eclipse.jdt.internal.corext.util.AllTypesCache$TypeCacheDeltaListener@16 8afdd -> 0ms Listener #2=org.eclipse.jdt.internal.ui.packageview.PackageExplorerContentProvider@91cf0 b -> 0ms Listener #3=org.eclipse.jdt.internal.corext.refactoring.changes.WorkspaceTracker$JavaMod elListener@165547d -> 0ms FIRING POST_RECONCILE Delta [Thread[main,6,main]]: <NONE> The Java model delta doesn't contain the added CU CopyOfDummy.java, but fires some empty resource delta instead.
Philippe, can you please look at the two different deltas sent out. Is this a Java model bug or does the Java/UI have to handle the second delta specially.
I was also able to reproduce the problem with deleting the copied file after the test project has been opened and closed. Here is what I did: - close Test2 - reopen Test2 - reveal CopyOfDummy.java - select it - execute delete Here is the corresponding delta trace: ------------------------------------------------------------------------------- ---------------------------------------- FIRING POST_CHANGE Delta [Thread[ModalContext,6,main]]: Java Model[*]: {CHILDREN | CONTENT} Test2[-]: {} ResourceDelta(/Test2)[*] Listener #1=org.eclipse.jdt.internal.corext.util.AllTypesCache$TypeCacheDeltaListener@1f ed1fed -> 0ms Listener #2=org.eclipse.jdt.internal.ui.packageview.PackageExplorerContentProvider@45024 502 -> 0ms FIRING POST_RECONCILE Delta [Thread[ModalContext,6,main]]: <NONE> ------------------------------------------------------------------------------- ---------------------------------------- FIRING POST_CHANGE Delta [Thread[ModalContext,6,main]]: Java Model[*]: {CHILDREN | CONTENT} Test2[+]: {} ResourceDelta(/Test2)[*] Listener #1=org.eclipse.jdt.internal.corext.util.AllTypesCache$TypeCacheDeltaListener@1f ed1fed -> 0ms Listener #2=org.eclipse.jdt.internal.ui.packageview.PackageExplorerContentProvider@45024 502 -> 0ms FIRING POST_RECONCILE Delta [Thread[ModalContext,6,main]]: <NONE> ------------------------------------------------------------------------------- ---------------------------------------- FIRING POST_CHANGE Delta [Thread[main,6,main]]: Java Model[*]: {CHILDREN} Test2[*]: {CONTENT} ResourceDelta(/Test2/src)[*] Listener #1=org.eclipse.jdt.internal.corext.util.AllTypesCache$TypeCacheDeltaListener@1f ed1fed -> 0ms Listener #2=org.eclipse.jdt.internal.ui.packageview.PackageExplorerContentProvider@45024 502 -> 0ms Listener #3=org.eclipse.jdt.internal.corext.refactoring.changes.WorkspaceTracker$JavaMod elListener@cde0cde -> 0ms FIRING POST_RECONCILE Delta [Thread[main,6,main]]: <NONE> ------------------------------------------------------------------------------- ---------------------------------------- FIRING POST_CHANGE Delta [Thread[Worker-7,5,main]]: <NONE> FIRING POST_RECONCILE Delta [Thread[Worker-7,5,main]]: <NONE>
Closing all perspectives in this state and reopening the Java perspecitve shows a package explorer still having both CUs CopyOfDummy and Dummy as children of the package dk.certus.eclipse. So CopyOfDummy still seems to be managed by the Java Model.
Interesting is that the CopyOfDummy doesn't have a plus indicating that the Java model doesn't know about its structure.
Jerome - pls have a look. Delta indeed looks curious. Surprised there is no primary working copy flags and suspicious closings [-] as well ...
I suspect that the delta was generated using M8. That's why it doesn't have the PRIMARY RESOURCE flag set.
Was able to reproduce following Dirk's steps in comment #21. Problem in the DeltaProcessor that doesn't invalidate its cache of roots after the project is opened. Thanks to all for looking into this. Fixed DeltaProcessor#checkProjectBeingAddedOrRemoved(...) to mark the root list as stale when a project is open or closed. Added regression test JavaElementDeltaTests#testAddCuAfterProjectOpen().
*** Bug 61864 has been marked as a duplicate of this bug. ***
*** Bug 62367 has been marked as a duplicate of this bug. ***
Verified in 200405281200
