Community
Participate
Working Groups
Created attachment 104577 [details] screenshot of selected SDKs to install Usecase: For testing an internal copy (emft.eclipse.org) of a public update site (download.eclipse.org) before publishing it. Steps to reproduce: 1. fire up eclipse-SDK-3.4RC4-linux-gtk.tar.gz 2. add http://emft.eclipse.org/modeling/emf/updates/milestones/ 3. search site and select CDO and Net4j RC4a builds' SDK features. 4. install 5. get attached log of errors I checked the update site, and the jars and packed jars are there, no problem. Now, granted, the site.xml contains this: <site pack200="true" digestURL="http://download.eclipse.org/modeling/emf/updates/milestones/" mirrorsURL="http://www.eclipse.org/downloads/download.php?file=/modeling/emf/updates/milestones/site.xml&format=xml"> but in the past, mirrorsURL was only a suggestion, not an enforced rule, and if the mirrors couldn't be found, the fallback was the local site. Is there a reason this behaviour has been changed? -- So... if this isn't fixable / shouldn't be fixed in p2land, then one workaround from my end might be to suppress the digestURL and mirrorsURL when the site is only a local copy (ie., when buildUpdateSite.sh isn't handed the -promote flag).
Created attachment 104578 [details] console log
Verified. Installing from the build server's test update site w/o digestURL and mirrorsURL works great. Just in case there isn't time to fix this for 3.4.0, I've implement the workaround in buildUpdateSite.sh so that we only have the following. <site pack200="true"> Still, it would be ideal if p2 could look at the local site before claiming it can't find the jars on any of the mirrors.
>but in the past, mirrorsURL was only a suggestion, not an enforced rule, and if the mirrors couldn't be found, the fallback was the local site. Is there a reason this behaviour has been changed? The fallback case has not been changed. The logic that is supposed to be implemented is: look for pack.gz if available and applicable, if the pack.gz can't be found (e.g. error while downloading) then default back to the "canonical" artifact (e.g. the regular jar). If you have an easily reproducible test case (or if I can remotely debug on the machine where the problem occurs) I would be interested. Were you installing from a p2 repo or from an UM site? This problem seems to be one of download. The control of the repository question is being handled in bug 235491.
Nick which version of the director are you using?
(In reply to comment #4) > Nick which version of the director are you using? Not sure what you mean by director. For creating the p2 metadata, I use releng.basebuilder from tag RC2_34, the latest released version. For trying to install from that update site, I used Eclipse 3.4RC4. (In reply to comment #3) > The fallback case has not been changed. The logic that is supposed to be > implemented is: look for pack.gz if available and applicable, if the pack.gz > can't be found (e.g. error while downloading) then default back to the > "canonical" artifact (e.g. the regular jar). Ah, but if you're searching for both of these on a mirror that doesn't contain them, do you fall back to the actual URL? That is, if you hit http://emft.eclipse.org/modeling/emf/updates/milestones/, and find that http://emft.eclipse.org/modeling/emf/updates/milestones/site.xml says: mirrorsURL="http://www.eclipse.org/downloads/download.php?file=/modeling/emf/updates/milestones/site.xml&format=xml" and you resolve that URL but don't find the requested update (Net4j 1.0.0RC4a, for example)... ... will you then simply check http://emft.eclipse.org/modeling/emf/updates/milestones/ for the jars and jar.pack.gzs (which are in fact present)? The only place any of the metadata files (digest.zip, artifacts.jar, content.jar) reference download.eclipse.org is in content.xml, extracted from content.jar: <references size='4'> <repository url='http://download.eclipse.org/modeling/emft/updates/' type='0' options='0'/> <repository url='http://download.eclipse.org/modeling/emf/updates/' type='0' options='1'/> <repository url='http://download.eclipse.org/modeling/emf/updates/' type='1' options='1'/> <repository url='http://download.eclipse.org/modeling/emft/updates/' type='1' options='0'/> </references> Would it help if the actual site (http://emft.eclipse.org/...) was listed there too? > If you have an easily reproducible test case (or if I can remotely debug on > the machine where the problem occurs) I would be interested. Yes, the one I documented is easily reproducible. See comment 0. > Were you installing from a p2 repo or from an UM site? A p2-enabled UM site, of course -- we long ago put to bed the issue of updates sites needing p2 metadata (except that one about Europa being enhanced w/ p2 metadata). You can browse the directory here, where you'll find digest.zip, artifacts.jar, and content.jar: http://emft.eclipse.org/modeling/emf/updates/milestones/ If you'd like ssh access, I can give you that too. Hell, you can reproduce the entire update site (or at least a single Net4j update) using my script on your local machine, simply by pointing it at a mirror of this directory: http://emft.eclipse.org/modeling/emf/net4j/downloads/drops/1.0.0/S200806111344/ I can walk you thru the setup if you'd like -- you just need rsync to grab the directory then to fire a shell script to extract the jars, generate the site.xml, & create the digest & p2 metadata.
Could you please write a test to ensure that we worried mentioned in the title is not happening. Thx.
Created attachment 130450 [details] UpdateSiteFactory patch The patch fixes pack200 support for UpdateSites and enables mirrors. The test case also requires a few additional files to follow
Created attachment 130451 [details] Data for testcase I modified an existing update site repository to enable pack200 and mirrors, the zip simply contains pack.gz versions of the plugin/feature files found in: /org.eclipse.equinox.p2.tests/testData/updatesite/site
Created attachment 130467 [details] Test for fail over from packed to canonical descriptors
*** Bug 227633 has been marked as a duplicate of this bug. ***
This has been fixed in HEAD. We will be adding a few more tests.
