We have a setup where we are able to perform a workspace setup automatically.
Some people in our team creates a workspace to work on a bugfix and then throw it away.
Currently in our each of our project metadata, we have our
.settings/org.sonarlint.eclipse.core.prefs that are referring to our SonarQube Server.
So in a new Workspace, what people needs to do:
- Open the " SonarQube Server " View
- Select “Connect to a server”
- Configure the URL of our SonarQube Server
- Select Username + Password
- Enter their credentials
- Let the defined server name as proposed (each team member needs to have the same name)
I consider this procedure as OK, but it is still too much for some of the team member and it reduce the acceptance of the SonarLint Plugin in our team.
In addition when the server is not correctly defined, the SonarLint Console in the console view capture the focus to display some errors. This is something that some team member do not accept.
In order to avoid that people now de-install the SonarLint server (as a single fix that solve all the error they get in each of their workspace) I need a solution.
- It is possible to share the credential across the team? (we could work with a common token)
- Is is possible to do the setup in an automated way. Even manual editing of an hidden file in the
.metadata folder would be fine (as soon as we can automate it)
- Is there a way to tell the SonarQube plugin it should react differently (bringing the SonarQube Console View in foreground is something really strange for Eclipse User. I understand that this is valuable information, but other member of my team consider it as noise. I do not think that other Eclipse plugins disturbing the flow when something is not correctly configured)
Thank you a lot for all the inputs you can give me.
PS: I consider SonarLint/SonarQube as a great tool. Thank you for all the work.
sadly i can not help or answer anythingthing helping your cause.
I am just answering because i would like to second your request for some changes to the workflow that SonarLint imposes. I, too, would like to be able to better support my team with these administrative tasks by automating some of them away.
Some time ago i also was looking for a way to automate some of the steps that are needed to get things going. I was hinted to the Ooomph-Way-Of-Doing-Things (which was too complicated for me to have “a quick look at” yet)
I also very much like your 3. valid suggestion (and also the humble hint to behave nicely in a “not owned ecosystem”)
The point 3 is also something that can be configured in the UI:
So this is only about a default value that does not help with the acceptance of the plugin…
Are you providing a custom Eclipse bundle to your developers? Or are you looking for a solution that would work only based on files stored in project SCM (ie that work with any project)?
Thank you for your reply.
With our current setup, we build a custom Eclipse IDE with all the plugins we need:
- Official plugins from Eclipse (mainly Java Dev Tooling + other)
- Some 3rd party plugins (I added SonarLint in this category)
- Some custom tools just for our project (something we build and that is only for us)
Then we have a collection of scripts that do: installation/update/reuse of the correct IDE (appropriate stream, depending on the version of the product we are working on), creation of the workspace, checkout of the Git repo and materialization of our project in the Workspace…
=> This could be mostly replaced by Oomph, but our scripts were there before, so we did not change to use Oomph.
This is only for our team.
I will have a look at the
plugin_customization.ini that you are describing in the other thread.
I guess for a team as we are, it would be OK to share the token across the team.
As I said in the other thread, with the
plugin_customization.ini you can automate the creation of the server connection with the correct key and URL. But you won’t be able to store a token in the secure storage. Or at least I don’t know how to do that.