Community
Participate
Working Groups
Build Identifier: I20100312-1448 when i want to open a type in the OpenType-Dialog and a workingset is selected in the OpenType-Menu, than an error occurs. if there is no workingset selected, there is no error. ERROR-Message: "Type '...' could not be found in '...'. Make sure all workspace resources are refreshed. Reproducible: Always Steps to Reproduce: 1. select WorkingSet in the OpenType-Dialog 2. try to open a file 3. -> error: "Type '...' could not be found in '...'. Make sure all workspace resources are refreshed.
Created attachment 165536 [details] Screenshot
>when i want to open a type in the OpenType-Dialog From the picture I'd say the error dialog comes when you press 'OK', correct? Please try to figure out whether it happens for found/searched matches (below --- Workspace matches ---) and/or for types from the history (above --- Workspace matches ---). Also, for the type(s) that is reported as not found: is it possible that you changed that type recently or that it got touched/regenerated externally, e.g. via Ant script?
>From the picture I'd say the error dialog comes when you press 'OK', correct? Correct! >Please try to figure out whether it happens for found/searched matches (below --- Workspace matches ---) and/or for types from the history (above --- Workspace matches ---). type is in the history (it was opened sometimes) -> no problem type is not in the history -> error i was able to reproduce it: 1. select a workingset 2. try to open a type 3. -> error (type not in history) 4. deselect all workingsets 5. try to open the same type 6. -> success (type is in history) 7. select the same working set 8. try to open the same type again 9. also success >Also, for the type(s) that is reported as not found: is it possible that you changed that type recently or that it got touched/regenerated externally, e.g. via Ant script? The type isn't changed externally
(In reply to comment #3) > >From the picture I'd say the error dialog comes when you press 'OK', correct? > Correct! > > >Please try to figure out whether it happens for found/searched matches (below > --- Workspace matches ---) and/or for types from the history (above --- > Workspace matches ---). > type is in the history (it was opened sometimes) -> no problem > type is not in the history -> error > > i was able to reproduce it: > 1. select a workingset > 2. try to open a type > 3. -> error (type not in history) > 4. deselect all workingsets > 5. try to open the same type > 6. -> success (type is in history) > 7. select the same working set > 8. try to open the same type again > 9. also success > > > >Also, for the type(s) that is reported as not found: is it possible that you > changed that type recently or that it got touched/regenerated externally, e.g. > via Ant script? > The type isn't changed externally Please redo this scenario with the Search debug activated in the .options file, copy the entire output displayed in the console, paste into a file and attach this file to this bug. Please also let us know in which project/jar file is the type you try to open. With these informations, which should have better clues to understand what happens there. TIA
Created attachment 165542 [details] Debug Log
(In reply to comment #4) > Please redo this scenario with the Search debug activated in the .options file, > copy the entire output displayed in the console, paste into a file and attach > this file to this bug. > Please also let us know in which project/jar file is the type you try to open. > With these informations, which should have better clues to understand what > happens there. the project is Elba5_Program\at.racon_linz.elba.dfue.msgdataschreiber.sepa
(In reply to comment #6) > the project is Elba5_Program\at.racon_linz.elba.dfue.msgdataschreiber.sepa That does not match the data displayed in the Open Type dialog error shown in the provided snapshot... :-( Could you synchronize the data between the described scenario, the snapshot and the type name? For the type, please provide complete information, e.g. its full path (including it's name) from the project would be perfect :-) It also seems that the problem occurs for the Elba5_Program project, would it be possible to attach its .classpath?
Another question, have you verified the content of the Working set? Is it still up-to-date? I'm asking this question, because the content of the JavaSearchScope built from the working set looks really weird comparing to the JavaWorkspaceScope contents...!?
(In reply to comment #7) > > the project is Elba5_Program\at.racon_linz.elba.dfue.msgdataschreiber.sepa > That does not match the data displayed in the Open Type dialog error shown in > the provided snapshot... :-( > > Could you synchronize the data between the described scenario, the snapshot > and the type name? For the type, please provide complete information, e.g. > its full path (including it's name) from the project would be perfect :-) if I opened a type once, than it's in history, and the OpenType-Dialog has no problem, so i choose another file ... In that case it was: Elba5_Program\at.racon_linz.elba.dfue.msgdataschreiber.sepa.SepaConstantsAndTools.java
(In reply to comment #8) > Another question, have you verified the content of the Working set? Is it > still up-to-date? I'm asking this question, because the content of the > JavaSearchScope built from the working set looks really weird comparing to the > JavaWorkspaceScope contents...!? Yes the workingset is up-to-date! I think the JavaSearchScope looks different, because I selected a workingset in the OpenTypeDialog ... or am I wrong?
Created attachment 165693 [details] Classpath (In reply to comment #7) > It also seems that the problem occurs for the Elba5_Program project, would it > be possible to attach its .classpath? here it is
Frederic was asking to have the screenshot and the debug log for the same type. This could help us in making some inferences. Can you give the error screenshot for SepaConstantsAndTools.java? Where should AzUeberweisungSaveValidator.java be located -- Should it really be in Elba5_Program? Do you get these errors for the types in other projects in the working set? Do you get similar errors for the other working set?
(In reply to comment #10) > Yes the workingset is up-to-date! I think the JavaSearchScope looks different, > because I selected a workingset in the OpenTypeDialog ... or am I wrong? Yes I know that selecting a working will make the scope different than the workspace one ;-) What's bother me is that there are some package fragment roots in the working set I cannot see in the workspace scope list. That's theoretically impossible as the workspace scope should have *all* the package fragment roots visible in your workspace... Hence, that's why I said your working set scope looks suspicious. Could you attach the file where all the working sets are defined: .metadata\.plugins\org.eclipse.ui.workbench\workingsets.xml Thanks
(In reply to comment #12) > Where should AzUeberweisungSaveValidator.java be located -- Should it really > be in Elba5_Program? yes it should be in Elba5_Program > Do you get these errors for the types in other projects in the working set? in other projects i don't get errors > Do you get similar errors for the other working set? also in other workingsets (ELBA5_541) i don't get errors
Created attachment 165699 [details] Screenshot New (In reply to comment #12) > Frederic was asking to have the screenshot and the debug log for the same > type. > This could help us in making some inferences. > Can you give the error screenshot for SepaConstantsAndTools.java?
Created attachment 165700 [details] Debug Log New (In reply to comment #12) > Frederic was asking to have the screenshot and the debug log for the same > type. > This could help us in making some inferences. > Can you give the error screenshot for SepaConstantsAndTools.java?
Created attachment 165701 [details] WorkingSet (In reply to comment #13) > Yes I know that selecting a working will make the scope different than the > workspace one ;-) What's bother me is that there are some package fragment > roots in the working set I cannot see in the workspace scope list. That's > theoretically impossible as the workspace scope should have *all* the package > fragment roots visible in your workspace... Hence, that's why I said your > working set scope looks suspicious. > Could you attach the file where all the working sets are defined: > .metadata\.plugins\org.eclipse.ui.workbench\workingsets.xml > Thanks
(In reply to comment #15 and comment #16) I did it like in comment #3
>Created an attachment (id=165699) [details] [diff] >Screenshot New Isn't the element above '--- Workspace matches --- ' selected when clicking OK? If so, this would contradict to what you said in comment 3: >type is in the history (it was opened sometimes) -> no problem >type is not in the history -> error
Created attachment 165713 [details] have a look (In reply to comment #19) > >Created an attachment (id=165699) [details] [details] [diff] > >Screenshot New > Isn't the element above '--- Workspace matches --- ' selected when clicking OK? > If so, this would contradict to what you said in comment 3: > >type is in the history (it was opened sometimes) -> no problem > >type is not in the history -> error no its true! the '--- Workspace matches --- ' was inserted, after i pushed the OK Button ... have a look to the new video!
Crazy stuff! ;-) Question: The type that you try to open in the video is it - source or binary? - does it exist, i.e. can you open that type via Package Explorer?
Created attachment 165813 [details] Patch to print some more debug info Put some print statements to help narrow the problem.
Created attachment 165816 [details] core.jar Patched JDT/core jar
Please try using this core.jar and give the debug log and the .log file.
(In reply to comment #21) > Crazy stuff! ;-) its really crazy ;-) > Question: The type that you try to open in the video is it > - source or binary? its source > - does it exist, i.e. can you open that type via Package Explorer? yes i can open it via Package Explorer and also via Open Resource, when there is a workingset selected
Created attachment 165879 [details] debug log (patched) (In reply to comment #24) > Please try using this core.jar and give the debug log and the .log file.
Created attachment 165881 [details] .log (patched) (In reply to comment #24) > Please try using this core.jar and give the debug log and the .log file.
Thanks for the logs.. From the log, it appears that there's a project inside another project which is not supported in Eclipse. How are Elba5_Program and RACON_Common related? Can you give the .classpath of RACON_COMMON also? Can you also give the folder structure of both these projects? The first 2-3 levels should be useful.
Created attachment 166750 [details] folder structure
Created attachment 166751 [details] common .classpath
I tried to recreate the scenario here looking at the class path and the folder structure. I ran into another OpenType problem -- I am not able to open types in /Elba5_Program/generated. However, am able to open types in /Elba5_Program. Here, /Elba5_Program is the source folder and 'at' inside it is the included package folder. /Elba5_Program/generated is one more source folder. This nested folder has confused a part of the logic. We have a fix for this but I don't think this will fix the case we are seeing here. From the logs attached, we could see that somewhere it thinks that /Elba5_Program is in /RACON_Common, which is causing the problem. We could see that /Elba5_Program depends on the project /RACON_COMMON and /RACON_COMMON depends on the /Elba5_Program as lib. I tried my testcase using this scenario but couldn't reproduce the exact scenario. To get more information, I would like to give one more patch which could print some more required debug information. Hopefully this could help us to recreate the problem.
Created attachment 167280 [details] Patch to print some more debug info Put some more print statements to help narrow down the problem.
Created attachment 167283 [details] core.jar Patched JDT/core jar to print some more debug information.
Please use the latest core.jar or the code patch and give the debug log and the .log file, to help us narrow down the problem.
Dominik, in order to use the attached JAR you have to 1. replace the bundle-version in the MANIFEST.MF to match the one in your install 2. rename to the same name as the one in your install 3. replace the one in your install with this one
Created attachment 167437 [details] debug log (patched New)
Created attachment 167438 [details] .log (patched New)
Created attachment 167454 [details] Workspace that can reproduce the problem Thanks for the logs. I am able to reproduce the problem now. Attached is the workspace that can reproduce the problem. Use this workspace and try to open the type InAt, after selecting the working set 'ws' in the openType dialog. Project RACON_Common depending on Elba5_Program as library dependency is confusing the scope search. The relevant classpath entry in RACON_Common .classpath is <classpathentry kind="lib" path="/Elba5_Program"/>
(In reply to comment #38) > Project RACON_Common depending on Elba5_Program as library dependency is > confusing the scope search. The relevant classpath entry in RACON_Common > .classpath is <classpathentry kind="lib" path="/Elba5_Program"/> That's correct! When i delete this row the OpenType works without a problem Thank you!
(In reply to comment #39) Hi Dominik, Do you really need to have that class path entry in your project? Is this workaround good for you?
(In reply to comment #40) > (In reply to comment #39) > Hi Dominik, Do you really need to have that class path entry in your project? > Is this workaround good for you? Hi Satyam, right now we need this classpathentry, but we are still working to remove it. Thanks again for your help
Unfortunately, they are some indexing problems when a source folder is same as the class folder added through the build path. That class folder is expected to have only class files and hence that index is supposed to have only class files and if any non-class files are present, they are deleted. Thus, if it is a source folder, the index for the java files are deleted. It is very risky to fix this at this point of time in 3.6. Hence, we may not fix this for 3.6.
(In reply to comment #42) > Unfortunately, they are some indexing problems when a source folder is same as > the class folder added through the build path. That class folder is expected to > have only class files and hence that index is supposed to have only class files > and if any non-class files are present, they are deleted. Thus, if it is a > source folder, the index for the java files are deleted. > It is very risky to fix this at this point of time in 3.6. Hence, we may not > fix this for 3.6. To be a little more precise, JDT/Core index manager creates one index file per classpath entry. It stores the index files location in a map using the container path (typically the classpath entry path) as a key. In this peculiar case, two different projects have a classpath entry which has the same path. This makes the index manager mixing the index files for those two projects and we suspect also other tools (e.g. Search Engine) to be screwed up by this unexpected configuration... To fix this, we should at least change the way the JDT/Core index manager is designed and peculiarly how it retrieves the location of the index files. This is not something we can do at this late stage of the 3.6 development without high risk of side effects, hence we should at least report it to 3.6.1 or maybe 3.7 depending on the depth of the change and its impact on all the depending tools...
(In reply to comment #41) > (In reply to comment #40) > > (In reply to comment #39) > > Hi Dominik, Do you really need to have that class path entry in your project? > > Is this workaround good for you? > Hi Satyam, right now we need this classpathentry, but we are still working to > remove it. > Thanks again for your help Why, instead of the project itself, don't you use an explicit source and output folders for the Elba5_Program project (e.g. src and bin as the default proposal when one create a project)? This would workaround this issue as then the required lib classpath entry of RACON_Common project would have a different path (e.g. /Elba5_Program/bin) than the source one of the Elba5_program project (e.g. /Elba5_Program/src)...
Let's tentatively target this for 3.6.1 depending on the outcome of our further investigations. Please add a README entry for 3.6.
(In reply to comment #45) > Let's tentatively target this for 3.6.1 depending on the outcome of our further > investigations. > Unfortunately a first quick analyze on this shows that it would be a too big change to fit in a maintenance stream, hence this work will be done only in further versions... :-( > Please add a README entry for 3.6. > I'll write it and attach the corresponding patch to this bug (but only next week as we have a long week-end here in France :-))
Created attachment 169807 [details] Patch for adding the readme entry (In reply to comment #45) > > Please add a README entry for 3.6. Here's my proposal for the readme entry about this bug. Please let me know if this is OK and then I'll attach it (or a new patch with the remarks) to bug 313131...
- it's better if the title already says what's wrong - "screwed" is bad wording. - "So, to avoid" ==> "To avoid" >then I'll attach it (or a new patch with the remarks) to bug 313131... I can directly commit the patch once we have a final version.
Created attachment 169945 [details] New proposed patch for the readme entry Thanks Dani for the review. Here's the new proposal including all your remarks + Stayam's ones... If it's ok for you then please release it, TIA
>If it's ok for you then please release it, TIA Nice try: the patch contains the new and the old version ;-) Fixed in HEAD with some additional tweaks to better align it with the other items. Please take a look in HEAD.
(In reply to comment #50) > Nice try: the patch contains the new and the old version ;-) Ooops, sorry for that :-S > Fixed in HEAD with some additional tweaks to better align it with the other > items. Please take a look in HEAD. Looks fine to me, thanks Dani
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
