No. My reports don't get near that sophisticated! I'm not even sure how I'd approach it ... there must be some way using aggregator + p2 + URL connection tests, but ... it would take a week or two to program it (3 or 4 weeks for me :)
This is part of the reason why we stopped automatically discovering and adding repos to Juno repository: https://bugs.eclipse.org/bugs/show_bug.cgi?id=358415 But ... as soon as you start installing things that do have "pointers" to other repos, then p2 pulls in all those it can find automatically to your repository site list In bug 358415 it was pretty easy for me to get 80 sites!, many of those invalid just going by their appearance. Even today, I find myself going in every now and then and just deleting about all of them on my repository list. While not having them in common repo will help, unfortunately the way p2 works, it just sort of slows down the problem ... if someone kept installing new stuff, they would keep getting new update sites and it'd be the responsibility of those new features/repositories to fix up their old sites. The other "angle" on this problem is that p2 publisher (not sure about all of them, but at least the one from p2) puts the "repository info" it finds in features, right into the content metadata repository, and there it stays forever. As far as I know, there are no tools to go in and "edit out" old, invalid sites. (though, might be easy to write such a tool ... only a week of programming :) This was all done, by the way, with the best of intentions and designs, I think correctly, to maintain behavior similar to the old update manager ... but ... seems quantities have changed and the past is catching up to us. Sorry I do not know of a better answer. Maybe there is more that p2 could do before adding them? Maybe it's time to change that behavior or have as a user preference? I'm not sure what to recommend and hope others have better answers than I can give. From: Ed Willink <e...@willink.me.uk> To: Cross project issues <cross-project-issues-dev@eclipse.org>, Date: 05/26/2012 12:49 AM Subject: Re: [cross-project-issues-dev] update site URL Sent by: cross-project-issues-dev-boun...@eclipse.org Hi David I get some irritations from bad Update Site URLs; possibly because project A references project B and fails to track a rationalization of project B. Is it possible for one of your magic reports to detect bad Update Site URLs? Regards Ed Willink On 25/05/2012 22:39, David M Williams wrote: 3. I'm not sure where documented either, but the general advice, I've heard, and agree with, is for _products_ to include update sites but not features. So, EPP Java EE I know likes to include some for webtools, mylyn, others? And its makes sense for them as a "product" as it usually would for other adopters products or internal tools. But, it's considered best not to include them in features, and if so, not every feature, but only some few main ones. Inactive hide details for Greg Watson ---05/25/2012 05:22:44 PM---Hi all, I recall a discussion a while ago about update site UGreg Watson ---05/25/2012 05:22:44 PM---Hi all, I recall a discussion a while ago about update site URLs but I don't seem to be able to find From: Greg Watson <g.wat...@computer.org> To: Cross project issues <cross-project-issues-dev@eclipse.org>, Date: 05/25/2012 05:22 PM Subject: [cross-project-issues-dev] update site URL Sent by: cross-project-issues-dev-boun...@eclipse.org Hi all, I recall a discussion a while ago about update site URLs but I don't seem to be able to find the reference. So, a couple of questions: 1. Should we be providing update site URLs in our feature.xml files? 2. If so, do they need to be in every feature.xml, or only the "main" features? 3. If not, can I remove them from all the feature.xml files? There doesn't seem to be much documentation on this, but if anyone can point me to it, it would be appreciated. Thanks, Greg _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.2176 / Virus Database: 2425/5021 - Release Date: 05/25/12 _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
<<inline: graycol.gif>>
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
