Community
Participate
Working Groups
Let's imagine that there is an update site with URL: http://acme.org/update-site that is setup properly and works OK for a long time. At some point in time the webmaster of the update site may decide to move the content to a new URL: http://acme.org/new-update-site and simply make the old one /update-site to redirect to the new one /new-update-site. This way the users will still be able to update or download features by pointing to the old /update-site URL. Redirection is done by inserting a "redirect" meta tag in the index.html of the /update-site directory: <META HTTP-EQUIV="Refresh" CONTENT="0; URL=/new-update-site"> This way, requesting the /update-site URL returns HTTP response code 302 and points the HTTP client to repeat the /new-update-site URL. This scenario does not work at the moment. I have tried it with Eclipse 3.3 RC3. The error that is returned is: Error parsing site stream. [The XML stream is not a valid default "site.xml" file. The root tag is not site.] The problem happens, because the Update Manager tries to directly read the /update-site/site.xml file. It does not try to request first the /update-site URL and see that it has to redirect the request to a newer site. I know that this can be worked around by keeping the site.xml on the old URL and declaring tags in it that points to the new location of each plugin. But this is quite inconvenient for maintenance - every time a new feature or plugin is added or removed from the new update site URL, the site.xml on the old URL should be updated as well. The suggested solution is that the Update Manager first tries to read the URL of the containing directory of the site.xml and if: a) a "redirect" response code is returned, then to reiterate with the new URL b) response code different from "redirect" is returned, then to read the site.xml file.
Update does not read index.html - your solution assumes that Update acts as a browser and reads HTTP-EQUIV. It does not. It tries to open an input stream to parse site.xml directly.
Hi Dejan, As I have explained I understand that the Update Manager tries to read directly the site.xml. Redirecting the update site to a new URL is a valid use case and this bug should be consider at least as an enhancement. There should be a way for an update site mainainer to easily redirect the update site to a new URL without any future maintenance efforts involved. If the proposed suggestion for solution is not acceptable, I can give another one: add a redirect routine in the site.xml specification. This way a site.xml that redirects to new URL will looks as simple as this: <site redirectTo=<new_url> />
Note that admins can mirror update sites into the local LAN and provide a policy xml file that redirects searches for updates to this local mirror. Read the following document to see if it will help in your case: http://help.eclipse.org/help32/topic/org.eclipse.platform.doc.user/tasks/tasks-37.htm
No, the policy.xml file does not cover the use case, I am talking about. In my use case the feature is a downloadable server adapter for the WTP project. All users of any Eclipse/WTP-based product are potential users of this feature. The vendor of the server adapter feature contributes to the WTP codebase just an URL to the update site where this feature can be downloaded. There is a tool in WTP, based on the Update Manager that looks up the available URLs and displays the server adapters that can be downloaded. Now, the vendor of the server adapter may decide to move the update site to a new URL. And he also wants that the URL of the old update site redirects to the URL of the new one. This has to happen without any further steps on the user's side. Of course, the vendor may contribute the new URL to the WTP codebase, but this will apply for new release of WTP and the old release will be left broken.
The Eclipse Update component is no longer under development, and no longer exists in the Eclipse Platform 4.x stream. If this problem still occurs in Eclipse Platform 4.2 or later, please enter a new bug report against Equinox p2.
