Community
Participate
Working Groups
site.xml supports the notion of associate sites, where a site lists additional sites where content can be found. We currently don't support this, but should. - Minimally our update site repository (metadata/artifacts) should add associated sites automatically - We may need a similar concept on simple artifact/metadata repository as well. The associate sites could be added as properties to the repository by the generator when generating against an update site. See also UM bug 217229.
I could look at this when I work on bug 219904. Hmm... are you looking at this as a way to do something similar to mirror support?
This is different from mirror support. The associated sites are not mirrors - they are sites with additional content. For example in bug 217229, the update site for subversion has an associated site that provides a feature required by them (Mylyn).
I'll move to you... this isn't required for M6.
John, are these sites exposed in the Update Manager UI in anyway or just used underneath to get content? Will we then be able to see all of the content of that repo when asking for the IU's of the referring repo or a new repo will get added to the manager? I'm wondering if there will be any UI implications or if everything will "just work."
I'm not sure what the UM behaviour was. Apparently in Eclipse 3.3 it's a bit broken (see bug 217229). Pascal and I were chatting about this today, and thought it might tie into the discovery stuff related to ECF. I.e., if there was a button in the UI that said "Search for repositories", then associate sites is one of the things that could hook into that (rather than always eagerly traversing associate sites, which may be expensive). So, there might be some minor UI work in this area (not high on the priority list though).
Re: comment #5: I think that there is a difference between an "associate sites" concept and the general discovery mechanism. I think an associate site would be a good general purpose property on any repo. The associate sites should probably just get added by the repo manager itself when the repo with the associates gets added, or else the UI can drive it under the covers. No need for the user to visit the add repo dialog at all. I think there are several interesting use cases for this: 1) supporting old update manager per this bug 2) ability to create a really small repo that simply points to a bunch of cool content. Imagine a content.jar or even an update site URL that simply points to a bunch of cool sites, you could drag this jar from email or whatever, and voila! you can see a bunch of new software. Almost like a "favorites" list that could be shared. The "search for repos button" would be something different. I would expect to call some API that asked the repo manager for known sites in order to fill a list of known sites. This feels different to me. More discussion of that in bug #218534.
per bug #223981 it would be nice to have API to find out the associate repos for a repo, regardless of whether they are automatically added or not. This will allow us to smarten up our assumptions that artifact and metadata repos are colocated.
Moving to John as he publicly admitted working on it.
A general problem here is that we want repositories to be able to have associated repositories of different types. For example, a metadata repository may have an associated artifact repository. However, metadata repositories don't know about the concept of artifact repositories - they are orthogonal. To support this, I have added a DISCOVERY repository event type. When a repository has an associated repo, it broadcasts a DISCOVERY event with the URL of the associated repo. Repository managers listen for discovery events and add the discovered repositories to the set of known repositories. This mechanism can also be used for other repository discovery mechanisms, such as discovery sites in feature.xml, or ECF repository discovery.
Does this mechanism allow for repositories to not be automatically added? I think that automatic addition could become overkill when there are many repositories (e.g. imagine adding automatically all the repos found on the local network at work because we have ECF discovery on). I think it would be good to separate the mandatory repos from the "extra" ones that could be proposed for addition to a user. For that it may be enough to have a flag on the event.
Yes, it's optional. If you don't want the repository to be added, don't fire the DISCOVERY event.
Do you think we can enhance this mechanism to allow for advertisement of other related sites (aka discovery sites in UM terminology)?
>Yes, it's optional. If you don't want the repository to be added, don't fire >the DISCOVERY event. I think we could end up with most discovery extensions thinking their repo is important and therefore fire the event. I agree with Pascal that there may be cases where we just want to remember a discovered repo to show the user later (browse available...) whereas others we may want to add right away?
There are some remaining issues to work out, but I have released initial support so we can incrementally improve it as time allows. Here is what I have done: - when parsing a legacy update site, compute the associated sites and broadcast DISCOVERY events for each one. This will cause corresponding metadata and artifact repositories to be added the repository managers for the associated sites. - when parsing a feature.xml that has been "dropped in" to either eclipse/features or eclipse/dropins, broadcast a DISCOVERY event for each feature discovery site. This doesn't have quite the same semantics as original Update Manager associated sites - notably that the associated sites won't go away when the original site is removed, and that the associated sites will be available for all subsequent install/update operations, and not just the ones specifically scoped to the site that provided the associated sites. To answer the discovery questions raised by Susan and Pascal, I think we need to always add these repositories to the repository manager, because we may only ever parse the site.xml and feature.xml once to extract the information, and we need to hang onto that data somewhere or it will be lost forever. To avoid scalability problems we may need to be able to selectively enable/disable repositories, and I have entered Bug 226759 for this. I.e., support a state where the repository is known to the repository manager, and appears in the "manage sites" dialog in the UI, but there is checkbox that allows the user to say "don't look at this site". We may want to have the discovery sites from feature.xml disabled by default to avoid bloating the list of repos consulted by each install/update.
Note also that we can't reuse the exact "associate sites" implementation from UM for other p2 repositories since associate sites don't support the notion of repository types (metadata vs. artifacts). I have opened a separate bug to track adding a notion of associated repositories in p2 (Bug 226757).
John - it seems one thing we are losing with this approach is the old association. The fact that site "foo" is the one who referenced site "bar." If we maintained this association, then the UI (or the planner) could know to always include "bar" when updating or adding things located in "foo." As it is now, the UI only knows it has another pile of sites it could use for resolving and then the knowledge of which ones to use gets pushed onto the user.
