Configuration is a bit cumbersome. e. g. if I change the hostname, I then have to do "Get Projects" which doesn't change much and then I have to click "Apply to all modules" without much feedback, maybe this could be improved a bit. :-)

[Vampire]

No description provided.

[gshakhn]

Are you referring to the project configuration? The "Get Projects" button is there to verify that the hostname/username/password combo are valid.

What changes were you looking for specifically?

[Vampire]

project configuration, yes.
In this specific case I wanted to change "metrics" to "http://metrics" to workaround issue #23.
I went to the project settings, changed it and pressed "OK" just to recognize that it didn't have any effect.
I had to go in again, change the setting again, press "Get Projects" (Which should maybe called "Verify Settings" or even better "Test Connection"), then press "Apply to all modules" and only then the setting change had the desired effect. This is not too intuitive. Basically I just pressed every clickable button when it was clickable. g

[gshakhn]

Label has been changed. Let me know if you can think of a better workflow. :)

Thanks,
George

[Vampire]

Why do you need host / username / password / proxy setting per module anyway?
Are there really cases where you have different Sonar instances for different Modules?
If not, I'd remove those individual settings and the two "Apply ..." buttons from the project configuration and just take the project settings when connecting.
Also why do you need to do "Test connection" just to save a changed value or to be able to Apply it to the modules. If I don't want to test the connection because I know my change is good, I just want to press OK or Apply and have the settings changed.

[gshakhn]

Having individual module configuration was there just because it was possible, but project configuration does make more sense, especially since the PasswordStorage interface in #25 requires saving passwords on a project basis.

For the "Test Connection" option, it's there to verify the connection in one place. Otherwise, if a bad configuration is entered, other code paths would have to handle a bad configuration. Rather just handle it in one place.

[aheusingfeld]

+1 for keeping the settings on module level! We had a scenario not long ago when one of the modules of our project was actually a component-project on its own. Therefore I absolutely agree that there should be a checkbox saying "use project level settings" which if checked (the default) disables all input fields in the module level settings dialog.

On the comment about PasswordStorage: You could (and should IMHO) consider putting module into the "key" for the password retrieval. This means that before accessing PasswordStorage we need to check whether there are module specific settings but this way we preserve the ability to configure module specific settings at all.

[gshakhn]

I'm pretty sure we'll want/need to keep the "Sonar Project" configuration on a module basis. i.e.
Module A and Module B point to different projects in Sonar.

However, do we need different Sonar server configurations on a module basis? Will Module A and Module B point to different Sonar servers?

Making the latter case work shouldn't be that bad if we want. And we can put in the checkbox to use project level server settings on the module.
I'm tempted to make the "Sonar Project" configuration a required field on the module configuration though, and not come from the project configuration.

Does the above make sense?

[aheusingfeld]

I think that module settings should be optional and project settings should be pulled in by default if no module configuration is present. This way we don't force users to check/ set the configuration on module level.
To make this behaviour transparent to the user it is good practice in other plugins to disable input fields by default until "Use project level configuration" is deactivated. See Checkstyle plugin for example.

Nevertheless I think it's good to have the ability to specify a different sonar server on module level. Think of situations where you have a publicly available sonar and an internal installation.

[aheusingfeld]

I have another suggestion on workflow optimization for project settings:

1. if any field is changed mark the state as "modified"
2. combine the two buttons "Apply to all modules" and "Apply to all unconfigured modules" into a single combobox and make "Apply to all unconfigured modules" the default entry
3. execute "GetSonarProjects" and "Apply to modules" actions when the "apply" or "Ok" buttons in IDEA's project settings dialog are pressed

This should make configuration a lot more intuitive and prevent that we lose setting changes.

This came to my mind when working on #33. How do you think about it?

[gshakhn]

What happens in step 3 if the configuration is incorrect? Do we lose the (incorrect) settings? Do we prevent closing the configuration window?

If this changes makes the UI more intuitive for you, go for it. My UI design sucks and I'm always open to suggestions. :)

[aheusingfeld]

This has been moved to the new home of our plugin at sonar-intellij-plugin/sonar-intellij-plugin#16