As stated in the inital report:
"The odd thing was that we got MD5 errors when setting the target platform, but only on some machines."
Under the URL http://nexus/nexus/content/repositories/central/.meta/p2/artifacts.xml (Nexus with p2 plugin) you find for every osgi artifact a meta definition block like
<artifact classifier="osgi.bundle" id="slf4j.api" version="1.7.4">
<properties size="4">
<property name="artifact.size" value="26083"/>
<property name="download.size" value="26083"/>
<property name="download.md5" value="fe6474dc9ee70c418ef1df52e609810f"/>
<property name="repositoryPath" value="org/slf4j/slf4j-api/1.7.4/slf4j-api-1.7.4.jar"/>
</properties>
</artifact>
The same block with the same id exists for the test-jar but with different md5 hash.
So it seems like sometimes it resolves the test-jar and sometimes the real slf4j-api jar (because they have the same osgi bundle name). Then the resolver triies to verify the md5 hash of the downloaded artifact and in some cases the downloaded artifact and the meta information (see above) get mixed up so that the md5 hases don't match.
At least that is what i think was the problem. We haven't had that problem recently. Maybe it was somehow fixed/workaround by a nexus and/or p2 update in the meantime. (issue is from 02/2013 )
Nevertheless i think it should be fixed.
|