Bugzilla – Full Text Bug Listing
| Summary: | [repo] repo manager should favor client-settable repo name | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Susan McCourt <susan> | ||||||
| Component: | p2 | Assignee: | John Arthorne <john.arthorne> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | pascal | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | 3.5 M6 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 194224, 230322 | ||||||||
| Attachments: |
|
||||||||
|
Description
Susan McCourt
For the UI to dynamically show the change from no name to a producer name, we would want a CHANGED event to fire when the name property changed from null to some name when the repo was loaded (this might already be happening)... John and I discussed a few different solutions. First let's enumerate the problems with the current producer-defined repo name. 1 - you have to load the repo before the user can see the name (so you don't necessarily see the name in the pref page or when a new site is added via the install wizard). 2 - names defined in Eclipse 3.3 by the user are ignored when importing sites 3 - there is no story for translating the name for different locales Having a user settable name (bug 194224) helps with the issues in #2 and #3 but then the questions are: - what name is the default name when the user adds a repo - where is the name stored so that it's not overridden by the producers name? One idea is to get rid of the producer-defined repo name due to the problems above and instead just let the user store the repo name property. If a product wants to preconfigure a repo with a name, this is done with the addRepository touchpoint rather than setting a name in the repo. The advantage is that all names are always known (no change on load) but we lose the ability for the producer to name the repo. Disadvantage is compatibility conflicts with prior release and work needed on the publisher and touchpoint side to get repo names configured for a product. Another idea is to define a new property called NICKNAME that is also stored in the repo manager. The nickname is what the UI shows everywhere. If there is no nickname, then the repo name could be used if available. I think I prefer the latter idea because it doesn't change the behavior from a producer or tooling point of view, while helping with problems #2 and #3. Note it doesn't help us with problem #1. Another important part of this is whether the user *must* enter a nickname when adding a repo, and whether we provide a default name for them to use. Update Manager provided no default name and forced the user to type a name. This kept it simple. No magic from the user's point of view. However this makes it more difficult to support simple pasting or drag/drop of repo links. In those cases we'd have to make up a default name anyway. From a producer's point of view, we should default to a blank user name and not force the user to name anything. This would allow the producer name to be used unless the user specifically typed something. But I think this would be confusing to end users. So I guess I'm leaning toward going back to the UM way of doing it (forced naming, no default in the dialog, but a default name for drag/drop or paste adds). The alternative is to allow blank nicknames and add code to the UI that set the repo's NICKNAME to the producer's NAME as soon as the repo was loaded, if there was no other NICKNAME specified. This would mean that after the first load, the UI would always show the proper name for the repo, rather than having it disappear each time eclipse starts. What do you think, John? If we were to go back to the UM model, I think we want to make sure that the name is not required. just wanted to note that the dependent UI bug has 4 votes, so we want to do something for 3.5 Created attachment 125547 [details]
Add support for nicknames on repositories
I have released that patch to HEAD, so the UI should be able to start storing/retrieving repository nicknames. Things left to do: - Explore adding support for nicknames in AddRepository action - Make repository labels provided in feature.xml appear as nicknames - Repository events for nickname changes Created attachment 125588 [details]
Further nickname support
- added nicknames to repository event (discovery only)
- added support in generator/publisher to take discovery/update/associate site label and publish as nickname
(In reply to comment #7) > Created an attachment (id=125588) [details] > Further nickname support > > - added nicknames to repository event (discovery only) > - added support in generator/publisher to take discovery/update/associate site > label and publish as nickname > Is this in HEAD yet? I'll probably start working on the UI side of this early next week. Yes, this is in HEAD. I'm currently chasing down a bug that I think is a regression in the publisher, where feature update sites do not get published as repository references. I'll open a separate bug for that and mark this fixed. Feel free to open additional bugs for any remaining issues. My hope is that on the UI side it's simply a matter of looking for the nickname, and if it's not set, fall back to the original name property. That way we prefer the user-specified name, but failing that we use the repository-defined name if available. I found one other place I hadn't updated. The touchpoint actions that add repositories should also support setting a repository name. I have released a fix for this to HEAD. |