[ https://issues.jboss.org/browse/JBIDE-21043?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-21043: ------------------------------------- Ideally it would store a domain / username combination. Some may not even need to store the hostname, as they're already limited to using jboss.org / rht credential systems (see dl.runtimes).... Or, as another idea (not yet coded), it could also allow "Default Username" as an option... so for each host you could have multiple usernames but mark one as the default. Clients who want can store host+username, others could store host+"default username" option, which would allow them to resolve not only the password but also the username. But this seems a niche case... users aren't often changing usernames and deleting the old ones, but it does happen. The other plugins should be dynamically pulling the password. A plugin may contribute a domain (possibly through extension point? Currently just hard-coded jboss.org and access.redhat.com). It may make sense to put the domain in there for a few purposes: 1) The plugin must query for usernames at a given domain. By contributing the domain directly, the plugins can ensure the domain is properly typed in and has the exact id they will query on, minimizing error for users. 2) Users can see where they need to add the credential, so it helps guide the user as well. Well, for example dl-runtimes or openshift may need to query on a specific domain string, looking for all usernames with a given host. Users may not be consistant with how they declare the domain. They may type in 'jira.jboss.org' instead of just jboss.org, and then dl.runtimes won't know to query on jira.jboss.org. I also made this design decision because the tree is also easily navigable now in the secure storage page, split by domain, and properly encrypted, and I feel easier to read through in the case of debugging or digging around... I admit the PR is a work in progress, and I welcome all feedback for enhancement to cover more usecases. I like the idea of having configurators respond to changes in the credential model and then update dependent models (such as mylyn jira / bz) that cannot automatically reference this new credential area. -- This message was sent by Atlassian JIRA (v6.4.11#64026)