[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#papyrusIf 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
<<attachment: laurent_goubet.vcf>>
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
