[
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