-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue 207 - Add additional buttons für deleting and removing update sites to the dialog "Error Contacting Site" #343
Conversation
92657ac
to
b204735
Compare
@akurtakov @merks the build seems green so far can we integrate this? |
I see 4 failed builds. I don’t think they failed because of your changes though. |
Arggg... I missed the missing version bumps... @erik-brangs can you please increase the versions now? |
@erik-brangs thanks Jenkins succeeds now and I approved GH actions, can you probably squash your commits into one? |
...org.eclipse.equinox.p2.ui/src/org/eclipse/equinox/internal/p2/ui/LocationNotFoundDialog.java
Show resolved
Hide resolved
...x.p2.tests.ui/src/org/eclipse/equinox/p2/tests/ui/operations/LocationNotFoundDialogTest.java
Outdated
Show resolved
Hide resolved
07676b9
to
d09184b
Compare
@merks for me this looks sane now, a test is added that also succeeds so maybe we should give this a try? |
Trying it out locally, the first thing I tried was to add a bogus site and do check for updates, which fails like this: I realize that this PR does not try to address that case. Just entering/choosing a bogus site fails like this: which is also fine I suppose. If I enter a good site, but then ask for looking in All Available Sites, it fails like this, though I can close the dialog and ignore that failure: When I install something like this, I see exceptions in the log, but nothing in the UI about that: and the install succeeds: I actually have not been able to figure out when the dialog kicks in that I might test this manually. Perhaps someone can enlighten me how I can test this manually... |
You should see the dialog if you do the following:
I suppose there can be caching involved. I'm not sure what to delete to get a clean state. |
@erik-brangs can you verify the mentioned places by @merks so the dialog is showing there as well? |
Note that I don't want to block anything here. I would just be nice to see it in action... |
@erik-brangs do you plan to further work on this? Stream is open so you need to resolve the manifest conflict and rebase but this would be a good time for such changes. |
I will continue working on this pull request this month. |
I've taken another look. Here's an updated reproducer to get the dialog to show:
It seems the dialog does not appear on subsequent runs of the same Eclipse instance. I don't know why that is. I also can't seem to get the dialog when clicking through the UI of an Eclipse produced via Run Configurations from the default Equinox predefined setup. The stack traces differ for a downloaded Eclipse (which has Oomph)
and the Eclipse from the default Equinox setup:
I don't know how to proceed. Does it even make sense to attempt to change the dialog when it does not show in most situations? |
0969b77
to
2eeca52
Compare
Thank you for the hints. The dialog indeed only seems to be shown when accumulation of failures is disabled. Unfortunately, the new I don't see a way to handle the accumulated case without doing larger changes. Calling I have adjusted the original changes for the non-accumulated cases a bit. Is the PR suitable for merging in this state? PS: I don't know why the build failed. |
@erik-brangs I don't completely understand why the accumulation is not usable here, is it because you miss the exception? Can you share an screenshot of the dialog to illustrate the problem maybe? |
Thanks for the explanation and screenshot, that makes it now a bit clearer.
I think the best would be to check at the place where the error dialog is shown if the accumulated failures are only caused by updatesites not found (is this possible?). If that is the case, a dialog similar to yours can be shown that ask if they should be disabled or removed altogether would be enough, if it is just one single failed one then showing the existing dialog. If it makes things easier we also can always assume they are colocated I'm not aware of any case where a user can enter individual items. |
2eeca52
to
a34968f
Compare
I've tried to adjust the PR according to the feedback. I'm not sure why the ECA check fails. According to the Eclipse Foundation website, my ECA is current. |
@erik-brangs if you click on the failed check you should get additional information that (hopefully) help you to see whats wrong. |
I already did that and the error message made no sense to me. It said there was no ECA for my account which isn't true. The ECA verification tool on https://api.eclipse.org/git/eca/status/gh/eclipse-equinox/p2/343 says there's no Eclipse Foundation account for my email which can't be true because it just logged in with my account at the Eclipse Foundation website. |
Did you try the troubleshooting?
Also make sure that your github user is set in the account details. |
There seems to be a general problem with the ECA checks: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/4112 |
It seems the problem with the ECA check is fixed. Revalidation of the ECA succeeded. |
I find 4 buttons in a row is very heavy. Have you considered just adding a link to the "Install/Updates > Available Sites" preference page? |
In my installations, the "Available Sites" preference page normally has more sites than can fit on one page. In that case, I'd need use the filtering on the preference page. That means I have to remember which site failed. As I wrote in the original issue, one reason for the change was to relieve the user from remembering the failing site. |
These dialogs should not show up very often and the intention is for a user to quickly fix the issue "in place" without having to browse lists and perform additional steps so I think it is fine. If one wants the Dialog can be improved later on, as currently there is effectively no way at all as to dismiss the dialog completely. @merks do you think your concerns are addressed and this can be merged? Anything left now? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the host is bogus, it doesn't do much:
But if one specifies something bogus on an actual host, I finally see this dialog:
So that seems okay.
I have not reviewed the code in detail, I assume @laeubi will do that.
We should probably also rebase to ensure that we're not missing version increments.
I would say: something that do not exits, but yes we can assume that at least at one point in time the URL was valid and the udatesite just vanished (or most likely was http in the past). |
…ere update sites are not found (eclipse-equinox#207) Previously, if accumulation of load failures was enabled, all failures were put into a MultiStatus and displayed to the user. This has been changed to use more specific dialogs if possible. If all load failures were caused by repositories not being found, dialogs that allow removing or disabling the affected sites are used. If there is only a single load failure and it was caused by a repository not being found, the "Error Contacting Site" dialog is used. This commit extends the "Error Contacting Site" dialog with buttons for editing, removing or disabling a single site.
a34968f
to
8c2d65c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems some reformating not related to the change have slipped in
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's just trimming of unnecessary whitespace, probably via save actions. I can remove it later if it's that important.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks good.
Here's an attempt to fix the issues discussed in the first few posts of #207 , i.e. additional buttons for disabling and removing update sites. This PR does not implement any link rewriting as discussed later in #207.
I've made an attempt to write some tests but I don't know if that's the correct way to go about it. It's also not clear to me if events are needed for the operations. ColocatedRepositoryTracker also doesn't seem to use them. I've added TODOs for that in the PR.