Community
Participate
Working Groups
Setup: 1) main source is located at c:\p4\main\JavaApplications\ 2) Extra source is located at c:\p4\main\JavaApplications\test\ Project properties has both folders set as source and "test/" is excluded source #1. This exclusion was added automatically when I added the second folder. When I try to open a class by type (ctrl-shift-T) which is located at "c:\p4\main\JavaApplications\test\devtool\chat\ChatTools.java" it cannot find the file. It thinks the file is located at "test.devtool.chat.ChatTools" instead of "devtool.chat.ChatTools". This is true for all files contained in source #2. I have tried exiting eclipse. I tried refreshing the workspace. I have tried removing folder #2 from sources, exiting the project properties window, then re-adding it and waiting for the refresh to finish. This does not fix the issue. I have not tried deleting the project and recreating it. -- Configuration Details -- Product: Eclipse 1.3.1.20100913-1228 (org.eclipse.epp.package.java.product) Installed Features: org.eclipse.jdt 3.6.1.r361_v20100714-0800-7z8XFUSFLFlmgLc5z-Bvrt8-HVkH
I suspect you are going to have some pain as long as you have overlapping source folders. Not saying this isn't a bug, just saying that you're on thin ice.
Jay, please investigate.
(In reply to comment #1) > I suspect you are going to have some pain as long as you have overlapping > source folders. Not saying this isn't a bug, just saying that you're on thin > ice. How is this "on thin ice"? This is a feature that has existed in eclipse for a long time. The UI explicitly supports this using the Excluded list. Also, my entire company uses this feature and it worked fine for over a year on my previous desktop.
I am unable to reproduce this on HEAD. Are these source folders inside the java project or external? It would help if you can attach the affected project, the .classpath and the folder structure in particular.
Created attachment 184899 [details] .project
Created attachment 184900 [details] .classpath
folder structure c:\p4\main is the project root here is the general structure: JavaApplications\com\example\package JavaApplications\com\example\application JavaApplications\test\com\example\package JavaApplications\test\devtool\
Created attachment 184901 [details] Opening via Type note that the package is incorrect
Created attachment 184902 [details] Opening via Resource
Created attachment 184903 [details] Source tree setup
Created attachment 184918 [details] Screenshots Even with the given files, I am not able to reproduce the bug. I am attaching a couple of screen shots that show that the correct source folder is picked up. I tried this with HEAD as well as 3.6. Did I miss anything or something wrong with the set-up? Can you please try one of the newer builds? If you still find the issue, try isolating the issue in a sample workspace/project and please share it.
I am using Eclipse version: " Helios Service Release 1, Build id: 20100917-0705". When I check for updates, it tells me there is nothing to be done. My co-worker suggested the a potential cause. When creating a new project, you have the option to set roots. His theory is that we are setting up "JavaApplications" as the only root, and letting it parse the source. We then later go back in and add test as a root. Something then goes wrong such that it never completes the refresh and updates the package for the files contained in test/.
Created attachment 184992 [details] Junk project - example of bug
Aha, that comment may be the issue. Here are the rough steps: Create a new java project and add a single java file in src. create a folder inside src and put a java file in that. go into project settings and add the new folder as a root. Add a new class inside that folder (whee.java) Do not set a package on that class, since it will be at the top of a root. (it should automatically update the Excluded list, but for me it did not) Save the settings and refresh the project Open by type and type the class name. Notice that the class shows up in both the old and new locations.
What happens if you close/reopen the project ?
Created attachment 185089 [details] Example of broken test project.
For the small project, no it goes away after re opening the new project. It does do a re-parse before open by type does anything though. I just reproduced the "cannot find file" error on the test project. I have attached a screen shot. The steps are the same that I mentioned. This bug has been occurring on my primary project for a while now and exists across closing eclipse, closing the project, and refreshing the project. This may be related to the large size of my primary project. There are a LOT of files in it, 27,000 java files. Is it possible that the refresh is never actually completing and just silently failing?
Any progress on this, it still occurs 100% of the time for my team.
Jay, could you please investigate what is going on based on the latest comments ? If this requires more info, update the bug report accordingly. Thanks.
Just want to chime in that I see this frequently as well. I am a coworker of Mikel's. After reading through these comments, I don't think it was explicitly accepted that this is not 100% reproducible on our end either. That is to say that we cannot force this bug to happen at will, but it *will* eventually happen 100% of the time. Typically the project will start out in the correct state but at some point after a period of use it will revert to the incorrect structure. Given a project: Source#1 - /Java (exclude /test) Source#2 - /Java/test Once it is created and refreshed properly, a file may be located at: com.my.package.SomeClass.java (/Java/test) This will work correctly for a while (days, weeks, hours?), but eventually it will begin appearing in search results as test.com.my.package.SomeClass.java (/Java) Once that happens, selecting it from the search results gives a "file cannot be opened" error, because the file clearly doesn't exist at that path. It is very difficult to fix this state, usually requiring completely closing the project and Eclipse and then letting it refresh everything upon re-opening it.
Any update on this? This still occurs on all my active projects. My team members also have the same issue on their machines. I recently had my desktop completely replaced and did a fresh install of the entire system and the issue comes right back.
Can you give it a try using latest I-build ? For now, my understanding is that you reported the issue against 3.6.1. Did you try a recent Indigo build ? Jay, please update with what build you tried to reproduce. On comment 3, you mentioned that this worked. Could you please be more specific? What version did you use where this worked as expected ?
Gleefully installing indigo. Sadly, I don't know what version I was using, that was several years and 2 machines ago :).
Nope, still fails. Here are the steps I took: Install indigo open existing workspace wait for refresh to finish Attempt to open file in sub-root. Worked successfully, opened net/foo/bar.java inside test/ Sync my local source with source control using external tool Wait for refresh to finish Attempt to open file in sub-root. Failed with same error, could not find "test/net/foo/bar.java"
Jay, could you please work with Mikel to make sure you can reproduce the issue and understand what is going on? Thanks. Mikel, please make sure you talk with Jay so that he gets enough information to reproduce this issue. Thanks.
One of my co workers thought of something that might be helpful. We do not ever use Eclipse to build the java files. We use a command line script to build. We actually turn off Build Automatically because it takes a long, long time to build all 27,000 java files. Apparently some people suggest doing a build all to fix this issue, that is not something we would ever do. Also, after we build externally, eclipse has to refresh the project because of all the file changes. Not sure if those two items effect anything, but I thought it would be good to let you know.
I can reproduce this issue with I20110428-0848. It happens on two scenarios - a) When I add the nested folder to the source and add an exclusion in the parent source folder accordingly b) When nested source folder is removed from the list of source folders but the exclusion filter remains. In both cases, I see two entries and when I select the wrong ones, I get the error. However, things start working when I refresh the project. Copying Satyam for inputs. (In reply to comment #24) > Wait for refresh to finish Can you please check if there are any errors in the log file that indicate an indexing or refresh failure?
Where is the log file you want me to check?
(In reply to comment #28) > Where is the log file you want me to check? The logs get stored at: ${workspace_loc}/.metadata/.log
Created attachment 194513 [details] Log file
Created attachment 194514 [details] log backup 0
(In reply to comment #30) > Created attachment 194513 [details] > Log file Thanks for the log. I see the following errors in the log. !MESSAGE Background Indexer Crash Recovery .... !ENTRY org.eclipse.core.jobs 4 2 2011-04-28 12:50:27.529 !MESSAGE An internal error occurred during: "Java indexing... 479 files to index (/main)". java.lang.OutOfMemoryError: Java heap space The stack trace of the failing indexing job is available in the log and this seems to confirm my initial thoughts. You mentioned your workspace is big. What is your JVM heap parameters? Could you try with a higher value?
That is a false positive. When I setup indigo and opened for the first time I got an obvious heap space error. I had not adjusted from the default .ini settings. I closed and set the .ini to -Xmx900m and no error was shown.
These /might/ be steps to reproduce: Add java source tree add sub folder as a source refresh project (...guessing here) (refresh parses the first tree) (refresh STARTS parsing the second tree) (STOP the refresh) A file in the sub tree will have been incorrectly detected in the first parse and thus show up as part of the first tree.
I am able to reproduce the problem. This is similar to bug 312436, just a smaller problem than that and I do have a patch for this problem.
You are my hero :)
Created attachment 195590 [details] Proposed patch This patch should fix the problem. However, I think this could wait for 3.7.1.
Is there a 3.7.1 beta or nightly that includes this patch? I would be happy to test it.
(In reply to comment #38) > Is there a 3.7.1 beta or nightly that includes this patch? I would be happy to > test it. This is not yet released. I will add a test and then try to get it released on the 3.7.1 branch.
