Community
Participate
Working Groups
As described in http://jira.codehaus.org/browse/GRECLIPSE-953 and in http://jira.codehaus.org/browse/GRECLIPSE-918 there are some windows users who install Groovy-Eclipse and after doing so, the installation appears to install successfully, but the entry for org.eclipse.jdt.core is removed from the bundles.info file. The causes all JDT functionality to be missing from Eclipse. Unfortunately, I have not been able to reproduce this. I originally thought that this had something to do with installing into a read-only directory, but I do not believe that is the case any more. I don't know what is causing this, but it is troubling. Any ideas?
Originally, I thought that this was related to bug 332158, but I think this is a separate issue.
From the reporter of GRECLIPSE-953: "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." So, it does not appear to be a shared-install problem. Or am I misunderstanding what would cause a shared install?
An update from the user who originally reported the problem. He thinks it may be a proxy issue. Could this be true? <quote> 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. </quote>
(In reply to comment #3) > An update from the user who originally reported the problem. He thinks it may > be a proxy issue. Could this be true? I guess I can see how this can happen but this would be very weird. The download occurs, p2 thinks the download is successful, pass the jar to the simpleconfigurator that attempts to read the manifest of the jar which in its turn ditches it. Whether the problem is caused by proxy is not entirely clear. It may well be caused by problems with the connection, mirror containing corrupted files, etc... What I'm really surprised is that the error did not get caught since p2 has several mechanisms in place that would detect corruption: signature, unpacking, magic byte verification, or md5. So my question is does the artifact repository serving the file contains MD5 for the artifacts? If not, I strongly encourage you to add them (normally they are generated by p2).
I presume that the md5 signatures would be separate files in the repo? If so, no they are not generated. I did a brief google check bug couldn't find any information about how to add this to the repo. Can you point me in the right direction?
MD5s are automatically generated when you use Tycho or PDE Build. The MD5 are included in the artifacts.jar (e.g. <property name='download.md5' value='a919e04dbe4d80fdc14c6e90f5ebff69'/>)
