Comment 1 David Williams 2011-10-05 16:28:16 EDT

Thanks for the report. To cross reference, in Juno we should have less of these repositories in most installs, see bug 358415. 

But, now, for Indigo SR2, I could, in theory, figure out an regex repression to exclude repository URLs that are known to be problematic (using the --referenceExcludePattern option in b3 aggregator) but, obviously, would be better if the projects that "contribute" these URLs in their feature.xml files fixed them themselves. Or ... maybe I'm jumping to conclusions ... maybe those are the right URLs and they are simply broken repos and need to be fixed? 

In any case, the reported repos appear to all be from "modeling" ... so, let's see ... who do I know in "modeling" that could decide if new bugs should be open against their specific sub-projects? :) I'll assign to Ed for comments or disposition.

Comment 2 David Williams 2011-10-05 16:31:56 EDT

I should add, due to the nature of our "composite repositories" for releases, if there is a "bad URL" somewhere in the repository, it will likely be there forever. That is, not sure "filtering them out" will help all cases (but, to be honest, I'm not sure how "deep" p2 goes in "discovering" these, so fixing bad URLs would probably help most cases). 

Guess ideally the "reference URLs" could be a separate repo of its own ... but, that sounds like a lot of work (and http traffic?). 

... I'm open to suggestions ...

Comment 3 Ed Merks 2011-10-05 16:38:02 EDT

David,  

I'm not sure where these come from.  Teneo, for example, isn't part of the release train, so how does its update site end up appearing?  In the end, the individual projects contributing need to ensure that their contributions have valid update sites...

Comment 4 David Williams 2011-10-05 18:09:02 EDT

(In reply to comment #3)
> ... so how does its update site end up appearing?

Usually, they come, from someone including an update URL in their feature.xml. The "update site URLs" are "published" to p2 repositories, as reference URLs. 
The feature.xml would have something similar to

   <url>
      <update label="%updateSiteName" url=http://download.eclipse.org/modeling/emf/teneo/updates/1.2.0/releases/"/>
   </url>


I say "usually", since there are also ways to do add to a repository's "reference URLs" (contained in content metdadata) with p2.inf files. Hard to tell who might do that ... but, I recall it used to be popular with some modeling projects :) 

Now, from there, there are several ways to get into someone's IDE list of repositories. 

First, a user might install what ever feature has that update URL. 

Second, the b3 aggregator "publishes" update URLs it finds in "contributed" features. (This isn't a bug, its a feature :) 

Lastly, and here I think is where things "go wild" is that a client's IDE p2 will "peek" into enabled software sites, and retrieve the reference URLs it finds, and add them to the list (initially in 'disabled' state). I think this was intended as a "cool" feature to make sure user could find related or new things they might want ... and if just a few URLs used in a few repos that might work. 

But, as it is, people are not that aware of what they are publishing, and users end up with a ton of links. (Its relatively easy to get up to 80, as described in bug 358415). So, if nothing else, the law of large numbers would tend to include a few "bad" URLs in so many ... but, to make it worse, people don't really know what they are "publishing" (I think) since so much of it happens "automagically".

Comment 5 Bouchet Stéphane 2011-10-06 03:30:18 EDT

(In reply to comment #0)
> 
> http://download.eclipse.org/modeling/emft/eef/updates/releases/
> 

the update site has been fixed and now contains the latest version that can be installed in indigo

Comment 6 Eike Stepper 2011-10-06 03:48:04 EDT

Regarding CDO I think I know what the problem is. All my features in all branches contain this markup:

   <url>
      <update label="%updateSiteName" url="http://www.eclipse.org/modeling/updates/"/>
      <discovery label="%updateSiteName" url="http://www.eclipse.org/modeling/updates/"/>
   </url>

The referenced repository is the "Eclipse Modeling Project Updates" that has been created through bug 314388.

Apart from the fact that I've missed to request an update there due to our own new repositories layout I'm not sure what we're supposed to contribute to that composite repo.

We generally distinguish two "streams", i.e., integration and maintenance. It strikes me that users would not like to see drops from both stream types in that single Modeling composite repo because that could force them to update from their release-type initial install (via release train repo) to a not-yet-released integration install.

Would it make sense to have multiple (quality) Modeling composite repos?
Or is this idea too biased by our specific stream policies?

Comment 7 David Williams 2013-06-01 17:06:29 EDT

We "won't fix" in old repositories, but have addressed the problem in current Kepler repo (forget if we did it for Juno) but we no longer include "reference repos"). 

People can still end up with broken links if they install projects that use reference repos and those reference repos ... but, in those cases, bugs need to be open on the projects at blame.