Community
Participate
Working Groups
RC1 candidates. The RepositoryManipulationPage keeps a "local cache" repository tracker for repo manipulation that occurs while the page is open. For example, additions only add elements to the page, removals remove them, etc. No actual work with the repository managers is done in this page, except for "Reload" (refresh). In the case of reload, the user is trying to find out the actual status of the repo. Is it there? Are there errors? In this case, the repo managers must be contacted and in addition, the repositories might have to be added so that a refresh will actually work. (The manager won't refresh a repo it doens't know about). Right now this code is scattered in the UI code, such as RepositoryManipulation.refreshRepositories(). It makes more sense that this code should be in the tracker itself. The unreported error problems we had in bug 292831 could have been solved by having the local repo tracker report errors specifically. While fixing bug 292831, I focused on localized changes. But I think the right answer here is: - override localTracker.refreshRepositories to do the work done in RepositoryManipulationPage.refreshRepository() - the error handling in that method should pass to the local tracker handleLoadFailure rather than in-line - a remaining sticking point is the fact that the page knows that everything is colocated. The whole point of the tracker is that this should not be the case. We might want to consider lower level methods in the tracker which do the work, or return the managers that should be used (metadata, artifact, or both) but this is getting even more "cakey" than the current state. Perhaps we should strive to evolve RepositoryTracker into a customized error/reporter and event batcher, without having the convenience methods for add/remove/refresh. This would involve defining a runnable that the client runs during batching, and then the client can make decisions about colocation, etc. This would be API change.
(In reply to comment #0) > Perhaps we should strive to evolve RepositoryTracker into a customized > error/reporter and event batcher, without having the convenience methods for > add/remove/refresh. This would involve defining a runnable that the client > runs during batching, and then the client can make decisions about colocation, > etc. To clarify: this would involve a runnable that the client supplies, that the tracker runs as a batch operation. So the client can decide if it's refreshing metadata, artifacts, or both. And the tracker handles the event batching that occurs in the meantime. The client would have to specify whether the end result should be an update in the UI, but we have to be careful about the current assumptions made (see the end of ColocatedRepositoryTracker.addRepository(...)) where we are faking certain events to ensure the UI responds.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This bug was marked as stalebug a while ago. Marking as worksforme. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard tag.
