In reply to Laurent's note, (see below but with different subject line ... )
Short answer would be: Yes, there are problems, but nothing to "wreak some havok". Long answer: There's a few ways to explain what's going on, and to answer your questions, and to say what steps to take next. First, you'll notice those messages about "mirroring meta-data reference ...." are no longer in the juno aggregations, just indigo logs. This was covered in bug 358415 [1]. In short, it was decided not to copy the "reference repos" that projects have in their own repos, because there was too much junk in there, and despite _years_ of pleading, no one cleaned them up. But, it is true, still a problem with Indigo. And while less a problem in Juno, it is it still somewhat a problem even there, since if someone does "manually" add a new software repository to their list of sites, (or, if an EPP package does) and if that software repo happens to have "old" reference repos in it, then p2 will (still) copy them to the clients list of software sites (typically disabled, initially). p2 does this partially to retain functionality what was available with old update manager ... where one repo site could have a "sister site" they wanted users to see. But, without maintenance and careful thought this convenience just turns into junk. So, that steps to take? It is hoped that when it matters to consumers; users or adapters, they will open bugs against the specific projects to let them know they are bothered by the junk reference repos in those project's site. But this is similar to any other bug in another projects code ... there's nothing overall we an do to dictate which bugs they fix and which they don't. But the junk will no longer be in the common repo (beginning with Juno). The good news is some of the "junk" is left out or becomes irrelevant if users use the common repo. That is the Indigo Papyrus install will still work, and (in indigo repo) just add "junk" reference repos to the software repository list. I'm less sure what to say about the old Orbit repos. If they are reference repos, then the above applies. If people are still using them to actively get "old" Orbit content, then in most cases (but not all), when end users do installs, they still get only one, the newest version of a bundle installed by the way p2 works (and typically, only one would be used at runtime, though, agree it could mean some people test with one version, but end users are using another version). But, at best they are "wasting space" in common repo. But, it is not much wasted. There are only a few cases of obvious duplication. There's a report for that: http://build.eclipse.org/indigo/simrel/reports/nonUniqueVersions.txt Some cases in there make sense and are intentional for different parts of code to intentionally use different versions and both versions can coexist in same install and both run at same time (since non-singletons), such as javax.wsdl 1.6.2.v201012040545 1.5.1.v201012040544 But, others cases are just crazy and obvious cases of people not using the right Orbit repo or some how having their own, old copy in their own repository. javax.activation 1.1.0.v201005080500 1.1.0.v201105071233 1.1.0.v201108011116 Hope these (wordy) answers help explain a little. Feel free to open bugs against projects where you see issue with their repositories. [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=358415 From: Laurent Goubet <[email protected]> To: Cross project issues <[email protected]>, Date: 02/17/2012 04:37 AM Subject: Re: [cross-project-issues-dev] Fw: Indigo SR2 staging repo is complete ... again Sent by: [email protected] 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 [attachment "laurent_goubet.vcf" deleted by David M Williams/Raleigh/IBM] _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
