Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Fw: Indigo SR2 staging repo is complete ... again

When I look at the aggregator build log [1], I can see some references to "old" versions of the update sites? For example :

[exec] Mirroring meta-data from from file:///home/data/httpd/download.eclipse.org/modeling/mdt/papyrus/updates/milestones/0.8/SR2_RC4/main
     [exec] - mirroring artifacts referencehttp://www.eclipse.org/modeling/mdt/?project=papyrus#papyrus
     [exec] - mirroring meta-data referencehttp://download.eclipse.org/tools/gef/updates/milestones/
     [exec] - mirroring meta-data referencehttp://download.eclipse.org/modeling/mdt/papyrus/updates/releases/
     [exec] - mirroring artifacts referencehttp://download.eclipse.org/tools/gef/updates/milestones/
     [exec] - mirroring artifacts referencehttp://download.eclipse.org/modeling/mdt/papyrus/updates/releases/
     [exec] - mirroring meta-data referencehttp://download.eclipse.org/modeling/mdt/papyrus/updates/milestones/0.8
     [exec] - mirroring artifacts referencehttp://download.eclipse.org/modeling/mdt/papyrus/updates/milestones/0.8
     [exec] - mirroring meta-data referencehttp://download.eclipse.org/modeling/emft/eef/updates/0.7.1/
     [exec] - mirroring artifacts referencehttp://download.eclipse.org/modeling/emft/eef/updates/0.7.1/
     [exec] - mirroring meta-data referencehttp://download.eclipse.org/modeling/gmf/updates/milestones/
     [exec] - mirroring artifacts referencehttp://download.eclipse.org/modeling/gmf/updates/milestones/
     [exec] - mirroring meta-data referencehttp://www.eclipse.org/modeling/mdt/?project=papyrus#papyrus


If I am reading that well, this means that somewhere on the update site, someone is referencing a version of EEF (0.7.1) that is old, not contributed to indigo... and not built for this release altogether. EEF is itself contributed to the repository :

[exec] Mirroring artifacts from from file:///home/data/httpd/download.eclipse.org/modeling/emft/eef/updates/releases/1.0
     [exec] - mirroring artifact osgi.bundle,org.eclipse.emf.eef.mapping.edit,1.0.2.v20120216-1513
     ...

I believe that this might wreak some havok when people will try and install papyrus. I also saw references to three distinct orbit update sites in there:

- http://download.eclipse.org/tools/orbit/downloads/drops/R20100519200754/repository - http://download.eclipse.org/tools/orbit/downloads/drops/R20120119162704/repository
 - http://download.eclipse.org/tools/orbit/downloads/drops/updateSite

Wouldn't that be a potential issue waiting to bite the users?

As a side note, adding the update site into an eclipse and letting p2 do its job yielded an exception (full-featured with a nice, modal popup-dialog) that told me "No repository found at http://download.eclipse.org/gyrex/0.10/R-0.10-201106150229";. If I am right, this update site is now located on "archive.eclipse.org"... The issue is that it somehow ended up defined in my "available update sites" ... and made p2 fail.

This update site might have been there before I added the maintenance one in my eclipse's p2... but that will also happen to consumers. This raises the question : should we really archive the update sites? Changing the url of an existing update site, an url that gets added automagically to p2 when we browse other update sites or install other softwares (I don't even know what gyrex is, it just "got there") will make p2 throw an exception. Exception that is displayed in a modal, error-red popup displaying a message that is irrelevant to most users. I believe that 1) we should not change a published update site's url, whatever the reason and 2) p2 should log the exception, not open a popup dialog.

Laurent

[1] https://hudson.eclipse.org/hudson/view/Repository%20Aggregation/job/indigo.runAggregator/lastBuild/consoleFull
begin:vcard
fn:Laurent Goubet
n:Goubet;Laurent
org:<a href="http://www.obeo.fr";>Obeo</a>
email;internet:laurent.goubet@xxxxxxx
url:http://www.obeo.fr
version:2.1
end:vcard


Back to the top