Community
Participate
Working Groups
When updating to the latest version of mars, I have been getting sporadic problems with the Eclipse Mars update site due to complaining that http://download.eclipse.org/technology/epp/packages/mars/ is not a proper repository. It works if I add http://download.eclipse.org/technology/epp/packages/mars/R/ to my IDE.
The error message is a standard Equinox P2 one: No repository found at http://download.eclipse.org/technology/epp/packages/mars/. The message is slightly different if you try and add it to the main http://download.eclipse.org/releases/mars/ site because you get a stacktrace, saying /releases/mars/ isn't available because of a nested exception, and the nested exception has the above error message. I note that p2.index doesn't exist in the release, which presumably previously indicated that the compositeContent should be used instead.
The p2 index is broken beyond belief: http://download.eclipse.org/technology/epp/packages/mars/p2.index version=1 metadata.repository.factory.order= content.xml.xz,content.xml,! artifact.repository.factory.order= artifacts.xml.xz,artifacts.xml,!
Hmm... it appears that might be due to the new format released? https://wiki.eclipse.org/Equinox/p2/p2_index When I navigated before there was a p2.indexxx but not a p2.index - maybe that's fixed it.
Running this from the command line: ./eclipse -application org.eclipse.equinox.p2.director -repository http://download.eclipse.org/technology/epp/packages/mars/ -list works as expected (it produces a list). ./eclipse -nosplash -application org.eclipse.equinox.p2.artifact.repository.mirrorApplication -source http://download.eclipse.org/technology/epp/packages/mars/ -destination file:///tmp/blah and ./eclipse -nosplash -application org.eclipse.equinox.p2.artifacts.repository.mirrorApplication -source http://download.eclipse.org/technology/epp/packages/mars/ -destination file:///tmp/blah seem to work as well. So the only common feature is that Iw as updating an 4.5RC3 app to 4.5 in the two; perhaps there's been some caching of the site in the meantime because it was a previously launched Eclipse?
The p2.index file used to indicate the existence of a composite p2 repository, because this is how the milestones and release candidates were delivered. For releases (R, SR1, SR2) we've been using a single p2 repository since the Juno release some years ago. This part hasn't change since then, and is the same for Kepler, Luna, and now Mars. (The reason is simple: Better user experience, less requests to the download server.) But one thing that has changed is the new compression format of the content.xml, artifacts.xml files. In addition to the old .jar compression (content.jar, artifacts.jar), those files are now available as much smaller .xz compressed versions (artifacts.xml.xz, content.xml.xz), a new p2 feature in Mars. And this is indicated by the content of the p2.index file that you are seeing. As far as I can see, the p2.index isn't broken. It is bitwise identical with the one found in /releases/mars/201506241002/, but I wouldn't rule out that your issue isn't related to that.
Yes, if I replace http://download.eclipse.org/releases/mars/ with http://download.eclipse.org/releases/mars/201506241002/ http://download.eclipse.org/technology/epp/packages/mars/R/ then I can update an existing installation correctly. Note that I could do the same thing for both OSX and Windows using 4.5RC3.
(In reply to Alex Blewitt from comment #4) > So the only common feature is that Iw as updating an 4.5RC3 app to 4.5 in > the two; perhaps there's been some caching of the site in the meantime > because it was a previously launched Eclipse? Long story short... when I did my own tests with my own account on my machine I saw similar results. Then I retested it with a guest user, and everything was fine. I then thought that I must have seen some ghosts. But now you were reporting similar observations! Retest, again from my own account: Same problem. My Eclipse tried to download the (old) composite repositories. I then deleted ~/.eclipse/org.eclipse.oomph.p2/ mostly because it looked suspicious to me, not that I would now a lot about it, and re-run my test which was successful after that removal. So yes, I think you are right that there is some caching involved.
It looks like there's a P2 cache in there, which includes: http___download.eclipse.org_technology_epp_packages_mars_compositeArtifacts.jar http___download.eclipse.org_technology_epp_packages_mars_compositeContent.jar So perhaps this is being used as a configuration for a P2 repository with the epp_packages_mars as a composite repository, and that's confusing P2 somehow into not looking for it as a standalone repository?
Yes, looks to be a problem with Oomph. Somehow the list of cached p2 repositories that Oomph was injecting included the definition of the older mars update site as a composite repository, and so even though I was removing it from the preferences and re-adding it (which usually clears any cached repository data) Oomph was obviously doing something under the covers to confuse P2 into thinking it was a composite. I deleted the ~/.eclipse/*oomph* content and I was able to browse/update the Mars update site again. Just as well Markus thought to look here, otherwise it would have broken all future Eclipse installs as well ... Reassigning the bug to Oomph.
(In reply to Alex Blewitt from comment #8) > So perhaps this is being used as a configuration for a P2 repository with > the epp_packages_mars as a composite repository, and that's confusing P2 > somehow into not looking for it as a standalone repository? Yep, that should explain it. Maybe it would help to delete the outdated p2 repositories below technology/epp/packages/mars, in particular RC1 RC2 RC3 RC4 RC4a RC4b Those have been used in the old composite repository during RC-time. I'm going to remove them now (they are still available from archive.eclipse.org, just in case).
Is it possible that Oomph is adding a number of p2 repositories invisibly into Eclipse with no way of removing them from the UI? If so, that seems bad.
*** Bug 470912 has been marked as a duplicate of this bug. ***
I'm raising the severity to make sure this gets some visibility. I'm not sure what is cached in <userdir>\.eclipse\org.eclipse.oomph.p2 But it seems anyone who has downloaded a previous Mars milestone of the EPP's could hit this, I already know of several folks locally. Bad first impression of Mars as a platform.
I'd almost suggest changing the repo to a composite, where the children are simply "." ... or, would it be "../" ... or ... ? Normally this would break all those that have already "worked around" this, to remove previously cached value, and they'd have to delete those files, again. But ... I believe the p2.index file would allow both simple, and composite to exist at same site. Would just have to add to factories ... with composite being checked last, to avoid an infinite loop. Obviously should be tested on another "test site" before toying with the existing site. But, I think a p2.index of the following would work version=1 metadata.repository.factory.order= content.xml.xz,content.xml,compositeContent.xml,! artifact.repository.factory.order= artifacts.xml.xz,artifacts.xml,compositeArtifacts.xml!
The problem is that would break everyone who has downloaded a fresh copy of Mars since its release. That would be bad. The problem is a repository can be either a composite or a standalone (even if both artifacts are present) since Eclipse thinks it's an either/or. The real problem is that Oomph us caching p2 repository definitions and there's no way of removing them from the UI. You can't even uninstall Oomph from some packages and there's no way to stop it.
A better alternative may be to publish the epp repo in a different location and then update the Mars composite repo to point to the new epp repo location. The problem is its caching the old repo name/url but adding a new/different name should avoid the problem.
(In reply to Alex Blewitt from comment #15) > ... since Eclipse thinks it's an either/or. That is true, if there is no p2.index file. I can not say I have tested it, but do not think you read my original comment very closely. The p2.index file's purpose is to define a list of "factories" to try, in order. And, even if this would work "in general" ... no idea if it would work with Oomph ... I do not know what it is doing under the covers. (I suspect, from some notes I've seen, this is no mere cache, but a pre-built catalog -- I suspect that is to avoid creating the cache "first thing" -- and also suspect that the cache can be modified? Seems we are waiting for someone from Oomph or p2 to weigh in? > The real problem is that Oomph us caching p2 repository definitions and > there's no way of removing them from the UI. You can't even uninstall Oomph > from some packages and there's no way to stop it. Yes, what I was mentioning was purely a temporary work around. "Moving" things around might help ... but, do we really know what Oomph's behavior is then? (if a cached/catalog repo disappears?)
I had the same problem and deleting ~/.eclipse/*oomph* solved it for me as well.
Yes, it's very unfortunate that at the release transition point, 10 minutes to 4:00PM here at EclipseCon France, the Mars epp packages repo transformed from being a composite to being a non-composite. There's definitely a caching related problem associated with that, but of course one that was noticed at 10 minutes before the release. This problem would definitely affect anyone who has used the installer before and have cached repository information as a result. I was debating changing the catalog to refer to http://download.eclipse.org/technology/epp/packages/mars/R but at 10 minutes to 4:00 that seemed scary as well. But I've tested that this works well; of course it's a repository that no one has ever used before, so there can be no caching problem associated with it, and it's a repository that won't ever change so no future caching problem will affect it. When SR1 comes out or (goodness forbid there's an Ra or Rb), we can regenerate the catalog to refer to that, so also no caching problems. Fortunately this is also something that can be applied without anyone else changing anything nor do any bundles need to be updated to a fixed version, so that will give us time to track down what's no doubt a caching problem with the p2.index (which is cached because it avoids the typical 8 network requests to the main Eclipses server). Certainly all these problems would have been avoided were we able to test the final state of the repo with a little more than 10 minutes of lead time. It could also be avoided if the epp repo were always a composite, but of course composites are more expensive to use, though using the most recent child of a composite is cheaper to use (less metadata). It's not clear that making the epp repo both a composite and an aggregate would be a good thing; more likely that it's a source of other problems, i.e., which form has precedence.
The following changes have been committed: http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/commit/?id=be5a03c63aa577e8d220006d9d904310555adbf7 The archiver job has run and made the changes live. https://hudson.eclipse.org/oomph/job/setup-archiver/ I'll leave the bugzilla open to track down and eliminate the caching problem and have reduced the severity to reflect that fact that the immediate critical problem is address by virtue of publishing a product catalog that avoids the problem.
Does the catalogue get used for installs that haven't used the Oomph installer? Because all of the problems I had were with Eclipse installs that did not use the Oomph installer. They were simply packages that had Oomph previously installed (through the IDE for Committers package)
Yes Oomph itself uses those catalogs. But all p2 transport uses the transport layer that uses the caches.
Let me note succinctly that any user downloading a Mars package for the very first time will not see this problem, i.e., the vast majority of the downloads. This problme affects only users who have previously downloaded Mars milestones/RCs (or used the installer) and therefore have cached data about the epp mars repository being a composite as it was at that point it time. Deleting ~/.eclipse/org.eclipse.oomph.p2/cache will *permanently* fix the problem for such users, and that's the case even if I hadn't regenerated the catalog. The problem will not recur for SR1, even if we don't fix the underlying cause in Oomph. I.e., users of the Mars release will be able to update to SR1 successfully. Users have already confirmed that with the new product catalog the installer just works.
I had same issue. Deleting cache(~/.eclipse/org.eclipse.oomph.p2/*cache*) fixed this issue.
*** Bug 471528 has been marked as a duplicate of this bug. ***
I'm speaking out of complete ignorance here, but, did notice in the patch some statements such as <repository - url="http://download.eclipse.org/technology/epp/packages/mars"/> + url="http://download.eclipse.org/technology/epp/packages/mars/R"/> <repository url="http://download.eclipse.org/releases/mars/201506241002"/> And, just thought I'd point out if you used http://download.eclipse.org/releases/mars/ Then you'd get both 201506241002 and the technology repo (or composite). I'm guessing you are deliberately choosing the most specific simple repositories that you can? I do not know the purpose of this bit of code ... but, was curious. I know for *build* URLs, specific simple repositories are recommended (by me) but for *installation* URLs, composites are often used/recommended to allow "roll back". Just curious, if Oomph allows for roll-back? [No elaborate explanation necessary, just mildly curious.]
Thanks for the hint! We've also figured that out and tomorrow I'll implement the general solution to the problem.
*** Bug 471723 has been marked as a duplicate of this bug. ***
Sorry, it took a day longer but now I've committed the fix to master: http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/commit/?id=a35356a3c23c2dcec8b0035e534dec8137b09884 I'll kick a new milestone build in a few minutes, but in certain deployment scenarios it can be hard to update to it. So the easiest way of fixing the problem is to delete this folder: ${user.home}/.eclipse/org.eclipse.oomph.p2/cache I'd like to point out that this problem is only potentially relevant for users of former Mars developer builds, not all the new Mars users.
(In reply to comment #26) > I'm speaking out of complete ignorance here, but, did notice in the patch some > statements such as > > <repository > - url="http://download.eclipse.org/technology/epp/packages/mars"/> > + url="http://download.eclipse.org/technology/epp/packages/mars/R"/> > <repository > url="http://download.eclipse.org/releases/mars/201506241002"/> > > And, just thought I'd point out if you used > http://download.eclipse.org/releases/mars/ In fact we didn't realize that at the beginning. Out repo change in Oomph's product catalog only fixed the most immediate problem for the (not first-time) users of the *installer*. > Then you'd get both 201506241002 and the technology repo (or composite). > > I'm guessing you are deliberately choosing the most specific simple repositories > that you can? I do not know the purpose of this bit of code ... but, was > curious. It was to work around the caching bug in Oomph, the one this bugzilla is about. But appearently it didn't address all paths that lead to the problematic location (the one that changed the layout). Our new fix solves the bug at its root. And of course deleting the ${user.home}/.eclipse/org.eclipse.oomph.p2/cache folder also solved it for all paths. We'll change the repo URL back to the "main" URL for SR1 latest. Probably we can assume that most impacted users have deleted their cache folder earlier. > I know for *build* URLs, specific simple repositories are recommended (by me) > but for *installation* URLs, composites are often used/recommended to allow > "roll back". Just curious, if Oomph allows for roll-back? I don't think that anything in Oomph interferes with the revert functionality of p2. If that's what you asked ;-)
*** Bug 472005 has been marked as a duplicate of this bug. ***
> the easiest way of fixing the problem is to delete this folder: ${user.home}/.eclipse/org.eclipse.oomph.p2/cache Thank you for recording this nicely here, this has fixed a problem I've hit when trying to set up an Xtext dev workspace and was blocked by the following error, just recording this here for any future web search hits: Fetching content.jar from http://download.eclipse.org/technology/swtbot/releases/latest/ ERROR: org.eclipse.equinox.p2.transport.ecf code=1200 Artifact not found: http://download.eclipse.org/tools/gef/updates/milestones/content.jar. java.io.FileNotFoundException: http://download.eclipse.org/tools/gef/updates/milestones/content.jar at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryStatusHelper.checkFileNotFound(RepositoryStatusHelper.java:297) at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.checkException(FileReader.java:478) at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.sendRetrieveRequest(FileReader.java:435) at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.readInto(FileReader.java:358) at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.download(RepositoryTransport.java:101) at org.eclipse.oomph.p2.internal.core.CachingTransport.download(CachingTransport.java:111) at org.eclipse.oomph.p2.internal.core.CachingTransport.download(CachingTransport.java:188) at org.eclipse.equinox.internal.p2.repository.CacheManager.updateCache(CacheManager.java:402) at org.eclipse.equinox.internal.p2.repository.CacheManager.createCache(CacheManager.java:259) at org.eclipse.equinox.internal.p2.metadata.repository.SimpleMetadataRepositoryFactory.getLocalFile(SimpleMetadataRepositoryFactory.java:66) at org.eclipse.equinox.internal.p2.metadata.repository.SimpleMetadataRepositoryFactory.load(SimpleMetadataRepositoryFactory.java:88) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.factoryLoad(MetadataRepositoryManager.java:57) at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:768) at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.eclipse.oomph.util.ReflectUtil.invokeMethod(ReflectUtil.java:116) at org.eclipse.oomph.p2.internal.core.CachingRepositoryManager.loadRepository(CachingRepositoryManager.java:337) at org.eclipse.oomph.p2.internal.core.CachingRepositoryManager.loadRepository(CachingRepositoryManager.java:144) at org.eclipse.oomph.p2.internal.core.CachingRepositoryManager$Metadata.loadRepository(CachingRepositoryManager.java:387) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:96) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:92) at org.eclipse.oomph.p2.internal.core.ProfileTransactionImpl$RepositoryLoader$Worker.perform(ProfileTransactionImpl.java:1434) at org.eclipse.oomph.util.WorkerPool$Worker.run(WorkerPool.java:416) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Same issue here. I spent half a day trying to understand what was going wrong on my machine, when it was working perfectly fine on one of my colleagues' machine. I'm very glad that the new Eclipse error reporting tool pointed me to this bugzilla entry, via the "Related Problems" section of the submission report, or I could have spent quite some more time on this issue. p2 cache is now gone, and everything is fine again.
*** Bug 475248 has been marked as a duplicate of this bug. ***
*** Bug 477246 has been marked as a duplicate of this bug. ***
when I want to set up eclipse mars, I take a warning this "Took 6 seconds. There are failed tasks. Press Back to choose different settings or Cancel to abort." how can I fix this problem
(In reply to Eike Stepper from comment #29) > Sorry, it took a day longer but now I've committed the fix to master: > http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/commit/ > ?id=a35356a3c23c2dcec8b0035e534dec8137b09884 > > I'll kick a new milestone build in a few minutes, but in certain deployment > scenarios it can be hard to update to it. So the easiest way of fixing the > problem is to delete this folder: > > ${user.home}/.eclipse/org.eclipse.oomph.p2/cache > > I'd like to point out that this problem is only potentially relevant for > users of former Mars developer builds, not all the new Mars users. I found that replacing an older version of a plugin (Codiscope SecureAssist) with the newer one in our enterprise "software site" did not reflect in Eclipse PHP Neon's list of available plugins despite the older version not even installed. Looking at the software site's access logs I figured Eclipse's Help / Install New Software still attempted to fetch the older version of the plugin without even reading site.xml. Reloading the software site, starting Eclipse with "-clean" did not refresh the site's list of available plugins. Purging the Oomph cache did. I wonder why Eclipse Neon could not get Eike's fix considering that it was submitted more than a year ago?
There was indeed a bug recently fixed that a site.xml is cached and never updated. https://bugs.eclipse.org/bugs/show_bug.cgi?id=509891 You can delete the contents of ~/.eclipse/org.eclipse.oomph.p2/cache to work around the problem, i.e., to force any site.xml to be downloaded again.
I forgot to show the software site's access log with repeated attempts to read the older (3.0.2) version of the plugin despite a new site.xml pointing to the new 3.0.3 plugin files, 10.100.110.249 - - [04/Jan/2017:17:58:58 -0500] "GET /update/eclipse/digest.zip HTTP/1.1" 404 1001 10.100.110.249 - - [04/Jan/2017:17:58:58 -0500] "GET /update/eclipse/features/com.cigital.wbsa.feature.php_3.0.2.20160615211422.jar HTTP/1.1" 404 1105 10.100.110.249 - - [04/Jan/2017:17:58:58 -0500] "GET /update/eclipse/features/com.cigital.wbsa.feature.php_3.0.2.20160615211422.jar HTTP/1.1" 404 1105 10.100.110.249 - - [04/Jan/2017:17:58:59 -0500] "GET /update/eclipse/features/com.cigital.wbsa.feature_3.0.2.201606152113.jar HTTP/1.1" 404 1093 10.100.110.249 - - [04/Jan/2017:17:58:59 -0500] "GET /update/eclipse/features/com.cigital.wbsa.feature_3.0.2.201606152113.jar HTTP/1.1" 404 1093 10.100.110.249 - - [04/Jan/2017:17:59:28 -0500] "GET /update/eclipse/digest.zip HTTP/1.1" 404 1001 10.100.110.249 - - [04/Jan/2017:17:59:28 -0500] "GET /update/eclipse/features/com.cigital.wbsa.feature.php_3.0.2.20160615211422.jar HTTP/1.1" 404 1105 10.100.110.249 - - [04/Jan/2017:17:59:28 -0500] "GET /update/eclipse/features/com.cigital.wbsa.feature.php_3.0.2.20160615211422.jar HTTP/1.1" 404 1105 10.100.110.249 - - [04/Jan/2017:17:59:28 -0500] "GET /update/eclipse/features/com.cigital.wbsa.feature_3.0.2.201606152113.jar HTTP/1.1" 404 1093 10.100.110.249 - - [04/Jan/2017:17:59:28 -0500] "GET /update/eclipse/features/com.cigital.wbsa.feature_3.0.2.201606152113.jar HTTP/1.1" 404 1093 Seeing attempts to read digest.zip I ran a quick search online for "digest.zip site.xml eclipse software site", and it showed an article that might help as a work-around that could trigger Eclipse into downloading the "P2" style site (as opposed to "site.xml" one). I did not try this route. http://plosquare.blogspot.ca/2009/05/migrating-eclipse-update-sites-to-p2.html
Yes, p2 will always look for a digest.zip after it loads the site.xml. But if the site.xml is in the cache, the caching transport will always return the cached version. That's the bug that's fixed. Have you tried deleting your cache? It sounds like you haven't. If the site.xml is not in the cache, the caching transport will download the latest version. That should solve your immediate problem.
I did delete the cache and this updated the software site's view in my Eclipse. My previous comment aimed at software site maintainers who may feel uncomfortable asking every enterprise user purge their cache manually. I guess Ed's yesterday fix will eventually propagate into users' Eclipse through the hopefully working online update. Then no work-arounds such as converting "site.xml" sites to "P2" sites would be needed.
*** Bug 463635 has been marked as a duplicate of this bug. ***
10.100.110.249 - - [04/Jan/2017:17:58:58 -0500] "GET /update/eclipse/digest.zip HTTP/1.1" 404 1001 10.100.110.249 - - [04/Jan/2017:17:58:58 -0500] "GET /update/eclipse/features/com.cigital.wbsa.feature.php_3.0.2.20160615211422.jar HTTP/1.1" 404 1105 10.100.110.249 - - [04/Jan/2017:17:58:58 -0500] "GET /update/eclipse/features/com.cigital.wbsa.feature.php_3.0.2.20160615211422.jar HTTP/1.1" 404 1105 10.100.110.249 - - [04/Jan/2017:17:58:59 -0500] "GET /update/eclipse/features/com.cigital.wbsa.feature_3.0.2.201606152113.jar HTTP/1.1" 404 1093 10.100.110.249 - - [04/Jan/2017:17:58:59 -0500] "GET /update/eclipse/features/com.cigital.wbsa.feature_3.0.2.201606152113.jar HTTP/1.1" 404 1093 10.100.110.249 - - [04/Jan/2017:17:59:28 -0500] "GET /update/eclipse/digest.zip HTTP/1.1" 404 1001 10.100.110.249 - - [04/Jan/2017:17:59:28 -0500] "GET https://goo.gl/2DqXGj /update/eclipse/features/com.cigital.wbsa.feature.php_3.0.2.20160615211422.jar HTTP/1.1" 404 1105 10.100.110.249 - - [04/Jan/2017:17:59:28 -0500] "GET /update/eclipse/features/com.cigital.wbsa.feature.php_3.0.2.20160615211422.jar HTTP/1.1" 404 1105 10.100.110.249 - - [04/Jan/2017:17:59:28 -0500] "GET /update/eclipse/features/com.cigital.wbsa.feature_3.0.2.201606152113.jar HTTP/1.1" 404 1093 10.100.110.249 - - [04/Jan/2017:17:59:28 -0500] "GET /update/eclipse/features/com.cigital.wbsa.feature_3.0.2.201606152113.jar HTTP/1.1" 404 1093 Thanks!!
