Community
Participate
Working Groups
http://download.eclipse.org/eclipse/updates/3.6/R-3.6.2-201102101200/artifacts.jar starts with <?xml version='1.0' encoding='UTF-8'?> <?artifactRepository version='1.1.0'?> <repository name='"Eclipse Project Test Site"' type='org.eclipse.equinox.p2.artifact.repository.simpleRepository' version='1' <properties size='4'> and is missing a '>' after repository. This makes it impossible to update anything from Helios R/SR1 to SR2.
Sorry about that. Fixed.
I just tried again but it’s still failing for me on Win7. Does the change perhaps need to be pushed to any mirrors? When I load http://download.eclipse.org/eclipse/updates/3.6/R-3.6.2-201102101200/artifacts.jar in my browser the bug is still there.
It is possible that we are having trouble mirroring to the download server. Our new builds from last night did not show up either.
Uh-oh... when the Helios SR2 switch is flipped (was planned for 9am), bandwidth might go down even more. Isn't it possible to hand-edit that file right on build.eclipse.org ?
It *is* fixed on build.eclipse.org: build:~/downloads/eclipse/updates/3.6/R-3.6.2-201102101200> unzip -p artifacts.jar | xmllint --noout - But every request to the main URL http://download.eclipse.org/eclipse/updates/3.6/R-3.6.2-201102101200/artifacts.jar is redirected and ends up with the old version of the file: knauer@mk:/tmp$ unzip -p artifacts.jar | xmllint --noout - -:4: parser error : error parsing attribute name <properties size='4'> ^ ... I am assigning this to webmasters, maybe they can help.
I'm unable to replicate this. If I unpack the file on the server xmllint doesn't complain. If I download the file(either remote or my local desktop) and unpack it xmllint is still happy. Perhaps you were caught between Kims fix and the 'expiry' of the old file data in the file cache. -M.
(In reply to comment #6) > I'm unable to replicate this. I am now getting the correct file as well without being redirected to another download mirror.
On my Win7 box, "Check for Updates" in 361 still runs into the error when trying to install the update. I'll reinstall sdk361 from scratch and try again. There shouldn't be a cache involved when I "check for updates" in a fresh 361 install.
Ok, now even for me the Update scenario works on Win7. The "Checking for Updates" is SLOOOOOOOW (took around 15 minutes!!!) but once it finally got its content.jar and friends, the update itself was fast. I'd really appreciate mirroring to work better for content.jar & friends too!
