Community
Participate
Working Groups
I20090429-0100 When a match with a site name that looks like a URI is revealed, the UI will treat the whole match (name + actual location) as the actual repo location and this will cause problems. Steps - add http://www.taubit.de/eclipse/twitterclipse using the preferenes. Don't specify a name for the repo - install the software from it - restart - go back to the preference and now observer that the repo name is now something like file:/home/ivan/.... (side note, I don't understand why we did not get this name without the restart) - open available software, go to the work with and type in "twitter", type enter. You will get an error saying that a repo for file:/home/ivan is not available.
(In reply to comment #0) > I20090429-0100 > When a match with a site name that looks like a URI is revealed, the UI will > treat the whole match (name + actual location) as the actual repo location and > this will cause problems. > > Steps > - add http://www.taubit.de/eclipse/twitterclipse using the preferenes. Don't > specify a name for the repo > - install the software from it > - restart > - go back to the preference and now observer that the repo name is now > something like file:/home/ivan/.... (side note, I don't understand why we did > not get this name without the restart) This is bug 230322. Note that a restart is not required, only a reopen of the Installed New Software or repo pref page *after* the repo is loaded. You would have seen the correct name after completing the install (or doing anything else that caused the repo to load). > - open available software, go to the work with and type in "twitter", type > enter. You will get an error saying that a repo for file:/home/ivan is not > available. > I didn't follow the exact steps (I didn't complete the install, I just added the repo) and then selected it in the combo. And I didn't see the error or the strange name. Marking M7 to try the exact scenario described. This reminds me a little of bug 272894, which Martin saw and I could not reproduce. That one also involved a site becoming unselectable in the combo, although the circumstances were different. I will follow the exact steps from Pascal on a clean build/workspace and report back.
moving to RC1. I will spend some time on tomorrow's build trying to isolate the case, but I would not feel comfortable submitting a fix for it this late in M7.
(In reply to comment #0) > I20090429-0100 I tried this on M7 and could not reproduce. What I observed: > Steps > - add http://www.taubit.de/eclipse/twitterclipse using the preferenes. Don't > specify a name for the repo > - install the software from it > - restart > - go back to the preference and now observer that the repo name is now > something like file:/home/ivan/.... (side note, I don't understand why we did > not get this name without the restart) I observe that the site name is still blank > - open available software, go to the work with and type in "twitter", type > enter. You will get an error saying that a repo for file:/home/ivan is not > available. > I typed twitter and selected the URI, and the content for that site shows up. So the question is...where did that name come from? Do have a repository export file that contains the sites you normally use? I'm wondering if that is the name or path of a different site and somehow the names/sites got mixed up. If it was the path of some other site you were testing, then perhaps the indexes in the combo selection are off as described in bug 274330
Henrik & Remy - any help reproducing this would be appreciated.
Since the author's name appears to be Ivan Papic, perhaps some there was some packaging error on that end that caused the /home/ivan path to appear? I tried the steps described in comment 0 and simply got the same results as Susan's comment 3. http://www.eclipseplugincentral.com/Web_Links-index-req-viewlink-cid-1482.html
FWIW - Since a restart was required to get the error, I would look at the code that populates the data structure to form a hypotheses.
I'm starting to think this is an example of bug 275252, but we can't be sure without knowing exactly which error was reported. I think there were two things going on here: 1 - there are circumstances where the file path is used a repo name. This used to be the case in some of the headless apps and/or PDE export. I've lost track of when/which tools, but as an example, the i-build repo had a file path name for a long time. (Ian, can you elaborate?) (In reply to comment #0) > You will get an error saying that a repo for file:/home/ivan is not > available. > 2 - Pascal, I don't suppose you remember the exact error? If the repo was "not recognized" then somewhere in your workflow I believe the repo was disabled. When you then typed "twitter" you would get the disabled repo proposed in autocomplete and upon selecting it you would get the error from bug 275252 The location file:/home/ivan - http://www.taubit.de/eclipse/twitterclipse is not recognized. (In reply to comment #6) > FWIW - Since a restart was required to get the error, I would look at the code > that populates the data structure to form a hypotheses. > I'm not convinced a restart was necessary (for most UI-level bugs it matters little unless it involves reconciling dropins, etc).
In double-checking this code, I'm convinced that the only case where we would treat "Name - Location" as a repo location would be: 1) The user types/pastes/drags a string that contains "Name - Location" from somewhere and the URI is not known by the repo manager. Thus the string would be parsed as if it were a URI and there would be an invalid location error reported. Note this would happen regardless of whether the name looked like a file path or not. I think this was pure coincidence. 2) Assuming you did not paste this string in yourself, I believe that you encountered bug 275252. You said: > - open available software, go to the work with and type in "twitter", type > enter. You will get an error saying that a repo for file:/home/ivan is not > available. > This sounds like the twitter site had been disabled at some point. You typed in twitter and it proposed the "Name - Location" for twitter. Because we were not properly mapping this string back to the disabled repo URI, it was parsed as a location and you got the error. So I believe this part of the bug is fixed. However, I am still troubled by this: > - go back to the preference and now observer that the repo name is now > something like file:/home/ivan/.... (side note, I don't understand why we did > not get this name without the restart) There is some odd behavior I want to investigate with nicknames. Henrik has seen it too (bug 275479). The UI code is supposed to use the repo name as the nickname the first time it loads when a nickname is not otherwise specified. I want to make sure that this is being done consistently, as I'm also observing blank names that are not corrected after the first load. I'm not sure if restart is required, but something more than load is. Leaving this bug open for that part of it and retitling to focus on the remaining error.
*** Bug 275748 has been marked as a duplicate of this bug. ***
Created attachment 135662 [details] patch patch
Adding John for review. This patch fixes several different places that caused name-related bugs: 1 - it was possible to set a blank nickname from the repo pref page when none was specified. 2 - the UI cycles all repo loads through ProvisioningUtil in order to get the "if there is no nickname, check the repo name and use it instead" behavior. There was one place where this was not being done. 3 - even though we fix issue #1, we need to ensure that we correct previously saved blank nicknames. This is done in ProvisioningUtil.loadMetadataRepostiory(...), by ignoring blank nicknames, whereas before we were only checking whether the nickname was null. 4 - while correcting the code in QueryableMetadataRepositoryManager, I noticed a case where stale in-memory repos might be kept (a hunch in bug 275748). Since this is in the same code-space, I corrected it in this patch. The main issue is that QueryableMetadataRepositoryManager caches repo instances so that they don't disappear underneath it (necessary since the repo manager keeps soft refs). However, when retrieving repo instances for queries, etc., it should get the latest and greatest one from the manager, not the one that was cached. Usually these are the same instance anyway, but if the user refreshed a repo using "Test Connection" while the wizard was open, they could be different. Note that none of this affects the case where the user set a nickname. The question was, "why did it take so long to show the producer repo name in the UI". Here are the scenarios for verifying that names are now shown correctly after a repo is loaded. For each scenario, you have to start without the test repo in the settings and with cleared out repo caches. Use a test repo that you know has a producer-name. Scenario #1 - should work the same before/after the patch. - Add the repo by pasting/dragging the name in the Install new Software wizard. Result: The name doesn't appear at first (known bug), but the name should appear if you close and reopen the wizard. Scenario #2 - should work the same before/after the patch. - Help>Install new Software. - Open the prefs using the pref link. - Add the repo without a name. - OK. Result: The name doesn't appear at first in the wizard (known bug), but the name should appear if you close and reopen the wizard. Scenario #3 - patch improves behavior - Window>Preferences>Install/Update>Available Software Sites - Add the repo without a name. - OK - Help>Check for Updates, (OK/Cancel...we don't care about the updates, just want to load the repo through that code path) - Help>Install New Software, look for the repo in the combo Result before patch: repo doesn't have its name, you won't see it until restart Result after patch: repo has its name
Created attachment 135687 [details] Regression test in publisher tests I wanted an easy way to step through the problematic case, so I created a simple regression test. This test fails without the patch and passes with the patch.
Reviewed and released in HEAD.
