Installing groovy-eclipse 2.1.1 into Eclipse helios SR1 makes java functionality unavailable

This problem usually happens because your install directory is read only. Is your Eclipse installed in C:\Program Files?

It is not possible to install groovy-eclipse into a read-only eclipse install? See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=332158

I installed eclipse into C:\Developer\software\helios-test so not under any protected directories at all.
It's on a windows system and when unzip eclipse it does seem to make the directories appear read only when look in properties on a directory but doesn't restrict writing to the directory.
I tried reverting the install and then making all directories under helios-test non read only, then installing plugin again but same problem occurred.
It seems to download the jars to the plugins directory fine as I can see a new version of the jdt.core jar gets downloaded. This doesn't appear in the bundles.info file though and even if I manually add to the bundles.info doesn't help the java functionality re-appear.

I just raised https://bugs.eclipse.org/bugs/show_bug.cgi?id=334012 to track this issue. It appears to be a p2 problem.

You said that you edited your bundles.info file. What exactly did you add to it? It should look something like this:

org.eclipse.jdt.core,<VERSION>,plugins/org.eclipse.jdt.core_<VERSION>.jar,4,false

Where <VERSION> is the version of your patched jdt core jar in your installs directory. It should also be sorted properly by alphabetical order.

I added the line
org.eclipse.jdt.core,3.6.1.xx-20101215-2100-e36,plugins/org.eclipse.jdt.core_3.6.1.xx-20101215-2100-e36.jar,4,false

Just above the line
org.eclipse.jdt.core.manipulation,1.3.0.v20100520-0800,plugins/org.eclipse.jdt.core.manipulation_1.3.0.v20100520-0800.jar,4,false
in the bundles.info

I've managed to get it to work ok for me this morning though by installing from the zip download of version archive-2.1.1.xx-20101215-2100-e36.zip rather than from the update site.

Looking at the installation when I used the update site it looks like the jar org.eclipse.jdt.core_3.6.1.xx-20101215-2100-e36.jar hadn't fully downloaded and had been truncated (was smaller than when I installed from the zip file). I think the installation manager must have then removed the entry from bundles.info when it found a corrupted jar file. Didn't see any errors to say this though.
I suspect the proxy I'm behind might have caused the truncation.

All working now though.

Thanks for the update. It's good to know that you have gotten it working. And it's also good to know a potential fix in case other people have the same problem. I'm surprised that p2 didn't complain with any errors for that corrupted jar file.

I'm leaving this issue open for now until I hear back from the p2 team.

I am having the exact same problem with losing java features, specifically hover is the one I noticed. I am running on OS X 10.6.6 Eclipse 3.6. This only appears to be happening with the latest 2.1.1 update. I have full access to write files in the install directory and I am not behind a proxy.

While my preference is to be using the update site, I will also try the workaround above using the zip version.

Thanks,

Can you tell if the org.eclipse.jdt.core jar from the update site is truncated?

I have not tried using the zip file yet, but the size of the jdt.core jar files are the same 4.5 mb. It does not look like truncation is the issue here

I have also tried the the archive file and had the same results. This is now looking like a different problem from the original report. It is easy to reproduce the problem where combined hovers stop working in the eclipse editor only if I have the Groovy-Eclipse Feature installed. This happens on either my Windows or OS X machine. The other plugins I have installed are:
Maven
Subclipse 1.6.x

One additional note - Java combined hovers work with no problem when I load the archive version of 2.1.0. This problem appears only when loading 2.1.1

@Mike,

What exactly is the problem that you are seeing? Are you only seeing a problem with hovers and does you still have Java functionality after the problematic install?

We did make a change to the way that hovers work in 2.1.1. So, can you please explain exactly what is working for you and what is not?

Andrew,

I apologize for not being more clear. First the only problem I have currently is hovers, no other problems with java functionality.

The specific problem is this

• when the plugin is not installed, and I am in debugging mode (hovers set to combined) hovering over an active variable show the current value of that variable. This is standard behavior.
• when the plugin is installed, hovering over the variable, again in debugging perspective does not show the variable value the hover appears to default to javadoc only view.

Removing the plugin corrects the issue.

Please let me know if I can provide any additional information.

Andrew,

Looking at this a bit more I think I see where the problem could be... When the plugin is installed the second choice in the java editor hover is now 'Groovy Information Hover'. As I understand the combined choice it attempts to identify the best hover choice looking down that list. The 'best' choice is Variable Values' while in debugging mode (at least that is my best choice). I can manually select Variable Value and it works as expected. Could the addition of Groovy Information Hover alter the way 'Combined' works?

You are describing a very different issue from the installation problems above.

Are you seeing this behavior in Java code, or in Groovy code only? It is possible that this is coming from the Groovy Information Hover. I am currently on vacation and I am not able to look at this. However, could you raise a new bug for this and I will get to it as soon as I can?

The hover problem happens when debugging java code... You are correct this is a different issue. I have opened a new bug GRECLIPSE-978 to track it.

@Mike

Thanks. I am going to leave this issue open since we have not actually fixed the root of it (even though we have a workaround). I'll comment on the new issue.

Decreasing priority since we know of a workaround and there is not much we can do to actually fix this.

Resolving this issue now. There is not much else we can do. It is easy enough to recognize and diagnose the problem and then describe the workaround