Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #299746 +++ Bug 299746 comment 6 shows a separate problem while removing secondary types from the JavaModelManager cache: > Created an attachment (id=157034) [details] > Second stack trace after moving the .class files besides .java files > As mentioned before, my colleague moved the .class files back to the .java > files. > This resulted in another stack trace. Hence, I opened a separated bug to track this issue in the JDT/Core land...
In fact, what I would like to have was a trace file with the JavaModelManager debug activated when the exception occurs... I suspect this exception to cancel the Groovy uninstall process and lead to have some files/project not to be removed properly. So, I suggest that you execute the following scenario: 1) Start in a brand new wksp 2) Install the Groovy plugin 3) Load your projects 4) Leave the session 5) Restart the session with the JMM debug activated 6) Uninstall the Groovy plugin 7) Copy the console output in log file 1 8) Leave the session (I guess it's mandatory after the Groovy uninstall) 9) Restart the session with the JMM debug activated 10) Move the .class files besides the .java files (in fact, do the same operation than you did in comment 6) 11) Copy the console output in log file 2 12) Attach the 2 log files to the bug
bug 299746 should be closed as a duplicate of bug 286379.
As lead developer of the Groovy-Eclipse project, I will be happy to look at this. However, I am on leave right now for the next 5 weeks, so I can't spend much time on it.
(In reply to comment #1) > In fact, what I would like to have was a trace file with the JavaModelManager > debug activated when the exception occurs... I suspect this exception to cancel > the Groovy uninstall process and lead to have some files/project not to be > removed properly. OK, so I downloaded a fresh E3.5 SR1 copy and used a new workspace: > So, I suggest that you execute the following scenario: > 1) Start in a brand new wksp > 2) Install the Groovy plugin > 3) Load your projects Using "Import existing projects..." > 4) Leave the session > 5) Restart the session with the JMM debug activated > 6) Uninstall the Groovy plugin > 7) Copy the console output in log file 1 > 8) Leave the session (I guess it's mandatory after the Groovy uninstall) > 9) Restart the session with the JMM debug activated > 10) Move the .class files besides the .java files (in fact, do the same > operation than you did in comment 6) Since I did not do it myself, I can only guess the steps my colleague made: Configure build path and set the output folder for .class files from "all-macd/target/classes" back to "all-macd/src". Now the .class files are in the same directory ("besides") as the .java or .groovy files. But in this case no exception occured. > 11) Copy the console output in log file 2 > 12) Attach the 2 log files to the bug Will do in a moment.
Created attachment 159042 [details] First run installing the Groovy plugin (log file 0) This is not your log file 1, but log file 0.
Created attachment 159043 [details] Restart and uninstall Groovy (log 1) This is the first log you requested: Restarted workspace with debug/javamodel=true and un-installed Groovy plugin.
Created attachment 159044 [details] Restarted and changed class file output folder (log 2) This is your log 2. After restarting, I changed the project output folder for class files from "target/classes" to "src". Finally, I did the rename refactoring which used to fail. Now it worked.
Created attachment 159046 [details] Restarted workspace with pure 3.6 M5 Helios (Java build) After having re-installed the Groovy plugin by reverting to previous configuration and moving the output folder back to "target/classes", I left Eclipse and restarted with a freshly downloaded Eclipse 3.6 M5 Java build. Of course, this one did not contain any Groovy plugin. And now the rename failed with the attached exception java.lang.ClassCastException: java.lang.String cannot be cast to org.eclipse.jdt.internal.core.JavaElement at org.eclipse.jdt.internal.core.JavaModelManager.secondaryTypesRemoving(JavaModelManager.java:4439) at org.eclipse.jdt.internal.core.JavaModelManager.secondaryTypesRemoving(JavaModelManager.java:4370) There has been a patch in this area referenced by the other bug closed as duplicate. Is it this kind of error you are looking for?
Yes, this is the one I'd like to be able to debug. If you have any idea how I can reproduce this one myself, this would be really helpful.
(In reply to comment #8) > Created an attachment (id=159046) [details] > Restarted workspace with pure 3.6 M5 Helios (Java build) > Thanks for the trace, it was really helpful. I think I got the reason of this failure... I'll attach a patch soon.
Created attachment 159118 [details] Proposed patch There was a hole while building the secondary types caches allowing invalid entry values in the map, typically when indexes contain types which do no longer have a valid extension... I also the fixed the potential issue when removing a file extension, the secondary types caches need to be flushed to avoid keeping obsolete secondary types in the caches...
Note that closing and reopen the project(s) should fix the current issue even in the existing workspace as this both flush the secondary types caches and the index file...
(In reply to comment #11) > Created an attachment (id=159118) [details] > Proposed patch > Released for 3.6M6 in HEAD stream.
Hello Frederic, thanks for the quick patch. I really do appreciate this fast solution. Will we and the Groovy people benefit from this patch and the other other one: bug 286379 ( [search] Problem while searching class) in the 3.5 SR2 release? This would be wonderful. Thanks, Jörg
>Will we and the Groovy people benefit from this patch and the other other one: >bug 286379 ( [search] Problem while searching class) in the 3.5 SR2 release? No. 3.5.2 is basically done and this bug here is in Eclipse since at least 3.4.
(In reply to comment #15) > >Will we and the Groovy people benefit from this patch and the other other one: > >bug 286379 ( [search] Problem while searching class) in the 3.5 SR2 release? > No. 3.5.2 is basically done and this bug here is in Eclipse since at least 3.4. That's a pity since this issue effectively restricts the useability of the Groovy plugin in the same way as bug 286379 ([search] Problem while searching class) does it. Frederic, would it be possible to provide a point patch JAR file for both bugs to be applied to our local installation? I would be happy to test it and provide it to the Groovy people if it works. Many thanks, Jörg
(In reply to comment #16) > (In reply to comment #15) > > >Will we and the Groovy people benefit from this patch and the other other one: > > >bug 286379 ( [search] Problem while searching class) in the 3.5 SR2 release? > > No. 3.5.2 is basically done and this bug here is in Eclipse since at least 3.4. > > That's a pity since this issue effectively restricts the useability of the > Groovy plugin in the same way as bug 286379 ([search] Problem while searching > class) does it. > > Frederic, would it be possible to provide a point patch JAR file for both bugs > to be applied to our local installation? > I would be happy to test it and provide it to the Groovy people if it works. > > Many thanks, Jörg You can do it by yourself really easily... Just check-out the JDT/Core code of R3_5_maintenance stream from the dev.eclipse.org, apply both patches attached to the bugs and run the org.eclipse.jdt.core/script/exportplugin.xml as Ant Build... Then, rename the produced jar file with the same name than the one installed in your eclipse plugins dir (it should be org.eclipse.jdt.core_3.5.1.v_972_R35x.jar if you use 3.5.1) and restart your eclipse session with -clean argument on the command line... Of course, it would be a good idea to save the original 3.5.1 JDT/Core jar file in case you want to revert the patch... However, if this is true that the patch JAR is necessary for bug 286379, for this bug, as I said in comment 12, there's a really simple workaround: just close your projects and reopen them. This should flush the secondary types cache and the index file and then you should not face this issue again. Note also that the issue described in this bug only happens after having removed the Groovy plugin which adds an extension point for content type. It should work while this plugin is still activated, the problem only occurs after you did investigate the initial issue and remove the plugin. Hence, it's not true that it restricts the Groovy plugin usability...
(In reply to comment #17) > However, if this is true that the patch JAR is necessary for bug 286379, for > this bug, as I said in comment 12, there's a really simple workaround: just > close your projects and reopen them. This should flush the secondary types > cache and the index file and then you should not face this issue again. > Sorry, I was wrong, a new jar File is NOT necessary for bug 286379... The proposed workaround for this bug 302455 will also work for the bug 286379 issue: close all projects and reopen them in the workspace. Hence, this is definitely not fixes we will backport to the 3.5 maintenance stream.
Now I am got a bit puzzled: I understood that the workaround for both bugs, ie. bug 286379/bug 299746 and bug 302455 is just to close and open the affected projects. But I am afraid that the original issue, ie. that renaming constantly fails if the Groovy plugin is installed cannot be cured by just re-opening the project. And I definitely do not want to re-open the project before each rename refactoring :-) Please give me a hint were I am wrong: Does this mean that there is also a bug in the Groovy plugin? Many thanks for your help so far, Jörg
(In reply to comment #19) > Now I am got a bit puzzled: > > I understood that the workaround for both bugs, ie. bug 286379/bug 299746 and > bug 302455 is just to close and open the affected projects. > > But I am afraid that the original issue, ie. that renaming constantly fails if > the Groovy plugin is installed cannot be cured by just re-opening the project. > And I definitely do not want to re-open the project before each rename > refactoring :-) > > Please give me a hint were I am wrong: Does this mean that there is also a bug > in the Groovy plugin? > > Many thanks for your help so far, Jörg To be precise, I just said that the workaround works to get rid of bug 286379 and this bug (i.e. bug 302455) issues. The bug 299746 issue (ie. the stack overflow error) is a problem with the Groovy plugin (I've changed the bug status to make this clearer, see bug 299746 comment 42...), hence there's nothing else we can do from our side. I hope this is clear now :-)
(In reply to comment #20) > (In reply to comment #19) > > Now I am got a bit puzzled: > [...] > I hope this is clear now :-) Thank you very much, these clarification did help me a lot. There is already a Groovy plugin issue GRECLIPSE-642: Groovy plugin may break JDT rename feature completely http://jira.codehaus.org/browse/GRECLIPSE-642 and I will report your findings there. Thanks again for your help! A+ Jörg
Jörg, could you please verify that you no longer get the problem with one of the latest I-build ? Closing as VERIFIED for the verification process. Please report here once the verification is done. Thanks.
(In reply to comment #22) > Jörg, could you please verify that you no longer get the problem with one of the > latest I-build ? Olivier, I am sorry but I would need this patch for Eclipse 3.5 to verify it. The GRECLIPSE version 2.0.0Release which I need to verify this behaviour does not work with 3.6 Helios. The recent GRECLIPSE dev builds also works with 3.6, but also includes patches for the above GRECLIPSE issue GRECLIPSE-642: Groovy plugin may break JDT rename feature completely http://jira.codehaus.org/browse/GRECLIPSE-642 so I am not sure if I can reproduce this. Will try something next week.
