Bug 335300 - [ui] nickname property not reset if different repo is loaded off the same location
Summary: [ui] nickname property not reset if different repo is loaded off the same loc...
Status: CLOSED WONTFIX
Alias: None
Product: Equinox
Classification: Eclipse Project
Component: p2 (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: P2 Inbox CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords: helpwanted
Depends on:
Blocks:
 
Reported: 2011-01-25 07:43 EST by Helmut J. Haigermoser CLA
Modified: 2019-10-21 14:59 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Helmut J. Haigermoser CLA 2011-01-25 07:43:42 EST
Build Identifier: 3.6.1

When displaying a repository p2 uses the p2.nickname property from within the RepositoryInfo. This info could become outdated if a previous repository with a different name was loaded previously from the same location, and there is no code to reset the nickname once it's part of the repositoryinfo once ...

We've run into this when using DVDs, since there the path will always be the same, no matter if the customer changes DVDs:
/media/dvd/content.xml
would be a completely different repo to
/media/dvd/content.xml
;)

If the property "name" was used things would be OK, that property gets reset all the time...
Helmut

Reproducible: Always

Steps to Reproduce:
1. load repo "A" from path <path>
2. display repo in a tree (this will make use of p2.nickname prop)
3. load repo "B" from path <path>
4. the same tree will display the old name "A" instead of "B"
Comment 1 DJ Houghton CLA 2011-01-26 16:28:22 EST
When a new repository is added, the user is given the opportunity to set the nickname of the repo and it is used throughout the UI. I don't think we should be resetting (prompting?) the nickname if the repository contents change. Are you suggesting that we ditch the nickname property and use the p2.name property in the UI instead?
Comment 2 Helmut J. Haigermoser CLA 2011-01-26 16:51:33 EST
(In reply to comment #1)
> When a new repository is added, the user is given the opportunity to set the
> nickname of the repo and it is used throughout the UI. I don't think we should
> be resetting (prompting?) the nickname if the repository contents change. Are
> you suggesting that we ditch the nickname property and use the p2.name property
> in the UI instead?

Thanks DJ for the explanation, so that's where this nickname is coming from! :)
In my case no user ever had a chance to suggest a nickname, my suggestion would be to leave the nickname null and use the name instead for as long as the user does not specify a nick. p2.name gets reset correctly, fixing my issue along with it...

How does this sound?
Comment 3 DJ Houghton CLA 2011-01-26 17:06:45 EST
Sounds reasonable to me.

From a quick inspection of the code, it looks like it already handles that case when displaying a repo object. (looks for nickname first, then a name, then returns empty string)

But there is code in ProvisioningUI#load<Artifact|Metadata>Repository() which seems to set the nickname property to be the name if it isn't already set. I think this might prevent it from changing if the repo contents change. 

The code comment says that we set the nickname to keep the name in memory even when the repo isn't loaded. I'll have to dig deeper to figure out how we handle loaded/unloaded repos.
Comment 4 Helmut J. Haigermoser CLA 2011-01-27 08:12:20 EST
(In reply to comment #3)
> Sounds reasonable to me.
> 
> From a quick inspection of the code, it looks like it already handles that case
> when displaying a repo object. (looks for nickname first, then a name, then
> returns empty string)
> 
> But there is code in ProvisioningUI#load<Artifact|Metadata>Repository() which
> seems to set the nickname property to be the name if it isn't already set. I
> think this might prevent it from changing if the repo contents change. 
> 
> The code comment says that we set the nickname to keep the name in memory even
> when the repo isn't loaded. I'll have to dig deeper to figure out how we handle
> loaded/unloaded repos.

Thanks DJ, let me know if there is anything I can do to help! :)
Helmut
Comment 5 Thomas Watson CLA 2011-06-08 11:28:47 EDT
Move all 3.8 bugs to Juno.
Comment 6 Eclipse Genie CLA 2019-10-21 14:59:46 EDT
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.