Community
Participate
Working Groups
Repository managers should support for a user readable name to be associated with each repositories. This name should not be made mandatory. Also it may be interesting to have repositories provide a name for themselves.
+1. Right now all I can show in the UI is the URL and this is not very friendly for the simple user scenarios. And I don't think it should be mapped at the user level since a repo may want to name itself (as Pascal mentioned).
Just to clarify, we are suggesting that repos may define a name for themselves and that users may define a name for a repo. This makes sense to me. I assume that the user-defined name overrides the repo-defined name?
Dave has defined the name at the repo level. I won't worry about a user-defined name that overrides the producer's name until I am working on the exact use case.
Note sure what is happening here. Currently the repos we create in the code all have names etc. The names might not be that great but all the repo creation API allows for the name to be spec'd. What more is needed?
I left this bug open because there was talk of a name that the user could override (see comment #2). If the repo is not writable the user can't (and shouldn't) be setting its name. No one but the repo producer should set its name, but we may want to allow users to give it their own name. I'll tag this as a UI bug.
renaming to address remaining point
I am not familiar with p2 intrnal, but from the end user point of view it would be really useful to be able to name repositories created for classic update sites.
marking 3.4 so we can consider this
+1 for providing grouping by either specified site name or nickname. To date plug-in vendors have not had to name categories in a way that makes sense independently of the update site. For example, Mylyn's categories, spread across two different update sites, are: Features Feedback Integration Integration The result doesn't make much sense (see bug 225004) so as a temporary workaround Mylyn is in the process of prefixing all category names with "Mylyn -" and changing them to be globally unique.
When this is implemented, we would want to expand the import/export support in bug #224999 to read and write the name.
(This message is part of a bulk bug update.) Removing milestone. We are feature frozen for 3.4. These were good ideas but are simply out of time and need to focus on stability.
A related issue: I added http://downlaod.eclipse.org/eclipse/testUpdates to my list of sites, and in my list of available software, this site was listed. Then, after a restart of Eclipse, the name of the site changes to: file:/builds/I2008.....yada yada/src/repo now I assume that some local caching of the test update site happened, but this was a little confusing. Do you think we can keep the name of the original site?
Re comment #12 - see bug 230322
Weren't we going to fix the problem where the actual repo name (file:/builds/I2008.....yada yada/src/repo) was so ugly? I looked for the relevant bug but can't find it...
Susan: see bug 231215.
thanks, DJ, I annotated that bug because I still see the weird name in the I20080520 repo. Back to the topic of the bug...marking this 3.5 because there's been a lot of support for user naming, and in fact it's seen as a regression by UM users.
*** Bug 240797 has been marked as a duplicate of this bug. ***
"it's seen as a regression by UM users" There's no "seen as" about it: in Europa you could set repository names when you added them, in Ganymede you can't. When a new version of software can't do what an older version can, that's not "seen as" a regression, it IS a regression. To be honest, I don't why anyone would make this regression; why remove something (the repository name textbox in the add repository dialog) that nobody complains about and in fact many people use?
*** Bug 245242 has been marked as a duplicate of this bug. ***
*** Bug 256219 has been marked as a duplicate of this bug. ***
What I can do today (well, for M5...) is the following: - UI uses the repo manager name property to get the name as it does today - UI sets this property in the manager when it adds a repo (User has a name field in the add repo dialog and could possibly edit the name in the repo pref page). Until bug 259598 is implemented, the problem is that the user name would be overridden by the producer's name when the repo was loaded.
removing specific milestone as this depends on repo manager work to be done in bug 259598.
*** Bug 265592 has been marked as a duplicate of this bug. ***
Created attachment 126903 [details] work in progress attaching patch for John ... this is not polished, but demonstrates the use of the repo manager api.
fixed in HEAD >20090226. - there is a name field in the add repo dialog - you can edit the name in the pref dialog - nickname is not required - displayed name is nickname if not null, or else name if not null, or else location string - drag/drop operations and other "auto-add" gestures does not create a nickname - nicknames are now set when reading UM site bookmarks - displayed name (wherever it came from) is still exported as the site name One caveat is that until bug 265973 is fixed, the nickname is not being preserved across shutdown, but I tested with a partial patch John gave me and it will work when that is fixed. Added test cases that verify nickname import/export.
