Community
Participate
Working Groups
In trying to pin down the event sequence that can cause the "duplicate categories" problem, I've been adding some debug info to the repo event code. I unzipped releng tools and added the folder as a local repo. When I do this, I see an add event for the artifact and metadata repo (good) Followed by a discovery event for a referred repo in the future (good) Followed by another set of discovery events for the same repo (bad) Followed by the add events for the discovered repo (good) Here's the trace org.eclipse.equinox.internal.provisional.p2.core.repository.RepositoryEvent[source=file:/C:/_downloads/tests/relengtools]Type = 0 kind = 0file:/C:/_downloads/tests/relengtools org.eclipse.equinox.internal.provisional.p2.core.repository.RepositoryEvent[source=file:/C:/_downloads/tests/relengtools]Type = 1 kind = 0file:/C:/_downloads/tests/relengtools org.eclipse.equinox.internal.provisional.p2.core.repository.RepositoryEvent[source=http://update.eclipse.org/updates/3.3]Type = 0 kind = 4http://update.eclipse.org/updates/3.3 org.eclipse.equinox.internal.provisional.p2.core.repository.RepositoryEvent[source=http://update.eclipse.org/updates/3.3]Type = 1 kind = 4http://update.eclipse.org/updates/3.3 org.eclipse.equinox.internal.provisional.p2.core.repository.RepositoryEvent[source=http://update.eclipse.org/updates/3.3]Type = 0 kind = 4http://update.eclipse.org/updates/3.3 org.eclipse.equinox.internal.provisional.p2.core.repository.RepositoryEvent[source=http://update.eclipse.org/updates/3.3]Type = 1 kind = 4http://update.eclipse.org/updates/3.3 org.eclipse.equinox.internal.provisional.p2.core.repository.RepositoryEvent[source=http://update.eclipse.org/updates/3.3]Type = 0 kind = 0http://update.eclipse.org/updates/3.3 org.eclipse.equinox.internal.provisional.p2.core.repository.RepositoryEvent[source=http://update.eclipse.org/updates/3.3]Type = 1 kind = 0http://update.eclipse.org/updates/3.3 The UI is not being nailed currently by the duplicate discovery events, but I think after 3.4 we should try to get rid of the duplicate events as it can cause extra refresh or flash, and as we add better discovery UI it could cause problems. I would also like to see some descriptive toString() in the events themselves and tracing support in the provisioning event bus so that it's easier to debug issues like this.
I should add that I'm running with John's patch for bug #234177 in order to hammer the UI with add events, not sure if they affect this particular case.
I think this is expected because releng tools specifies the same site twice, as both a discovery site and update site: <update label="%updateSiteName" url="http://update.eclipse.org/updates/3.3"/> <discovery label="%updateSiteName" url="http://update.eclipse.org/updates/3.3"/> This would cause two events for the same repository since it is listed twice. The repository managers weed out the duplicate events and ensure only one ADD event is sent. I think the best answer is that the UI shouldn't listen for DISCOVERY events at all - they are intended as a way to communicate to the repository managers. The repo managers will then send an ADD event if there is actually anything new that was discovered. The person sending the event doesn't have the necessary context to figure out if the discovered site is new, or a duplicate (in the above example we could figure it out because it's coming from a single feature, but you often have two or more features that specify the same discovery URL).
Agree that the mainstream UI shouldn't listen for these (and it doesn't), although the manage sites dialog does since it shows discovered (disabled) sites. In future releases the discovery UI might become more important (as we add the support to discover repos through ECF, etc.) and it's reasonable assume to some parts of the UI will rely on this. So I think some weeding out would be useful, or else a repo manager discover(URL) API that does weeding out on behalf of the caller.
> although the manage sites dialog does since it shows discovered (disabled) sites. Whether the repository is enabled or not, the event sequence is the same. The repository manager receives the DISCOVERY event, and if it's not a duplicate it will broadcast an ADD event. I think the confusion is that we initially thought of discovery vs. add to distinguish whether the repository was enabled. I.e., discovered repositories would not be enabled by default. However due to various requirements we needed to split out the concept of "enabled", so now both DISCOVERY and ADD events work the same way regardless of whether the repository is enabled, and the method RepositoryEvent#isRepositoryEnabled was added for clients such as the UI that want to distinguish enabled vs. disabled.
OK, what that means is that the only UI that would want to listen to discovery events would be a discovery UI as discussed in bug #218534. That sort of UI would have to check for duplicates unless this bug is fixed. I'll make a note there.
I'm going to close this. The problem is that the code broadcasting the discovery event doesn't have the context to determine if the event is a duplicate. If it did have access to the repository manager it would just add the site directly and not broadcast an event.
