Add mono support (#2)

Added mono sonar scanner execution and options to pass custom mono installations. Keep in mind that mono is only considered when running in non-windows platforms. There also also some minor refactors and the .github folder.

Co-authored-by: Joaquim Neto <[email protected]>

.github/CODEOWNERS

@@ -0,0 +1 @@
+* larusso

.github/CODE_OF_CONDUCT.md

@@ -0,0 +1,51 @@
+# Code of Conduct
+
+## 1. Purpose
+
+At Wooga we are committed to providing a friendly, safe and welcoming environment for everyone who works here or with us, regardless to gender, gender identity and expression, sexual orientation, disability, physical appearance, body size, race, age, religion (or lack thereof) and game preferences.
+This code of conduct outlines our expectations for all those who work at or with Wooga, as well as the consequences for unacceptable behavior.
+We invite all those who participate in atlas-dotnet-sonarqube to help us create safe and positive experiences for everyone.
+
+## 2. Open Source Citizenship
+
+A supplemental goal of this Code of Conduct is to increase open source citizenship by encouraging participants to recognize and strengthen the relationships between our actions and their effects on our community.
+Communities mirror the societies in which they exist and positive action is essential to counteract the many forms of inequality and abuses of power that exist in society.
+If you see someone who is making an extra effort to ensure our community is welcoming, friendly, and encourages all participants to contribute to the fullest extent, we want to know.
+
+## 3. Expected Behavior
+
+The following behaviors are expected and requested of all community members:
+Exercise consideration and respect in your speech and actions.
+Attempt collaboration before conflict.
+Refrain from demeaning, discriminatory, or harassing behavior and speech.
+Be mindful of your surroundings and of your fellow Woogas. We encourage everyone to call it out if a dangerous situation, someone in distress, or violations of this Code of Conduct is noticed, even if they seem inconsequential.
+
+## 4. Unacceptable Behavior
+
+Unacceptable behaviors include: intimidating, harassing, abusive, discriminatory, derogatory or demeaning speech or actions by any employee, partner or customer here at Wooga, online and in one-on-one communications carried out in the context of teamwork.
+
+## 5. Consequences of Unacceptable Behavior
+
+Unacceptable behavior from any community member, will not be tolerated.
+Anyone asked to stop unacceptable behavior is expected to comply immediately.
+If a community member engages in unacceptable behavior, the community organizers may take any action they deem appropriate, up to and including a temporary ban or permanent expulsion from the community without warning.
+
+## 6. Reporting Guidelines
+
+If you are subject to or witness unacceptable behavior, or have any other concerns, please notify Wooga’s Equality and Diversity ambassador as soon as possible [email protected].
+
+## 8. Scope
+
+We expect all community participants () to abide by this Code of Conduct, in-person–as well as in all one-on-one communications pertaining to community business.
+
+## 9. Contact info
+
+[email protected]
+
+## 10. License and attribution
+
+This Code of Conduct is distributed under a [Creative Commons Attribution-ShareAlike license](http://creativecommons.org/licenses/by-sa/3.0/).
+
+Portions of text derived from the [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Geek Feminism Anti-Harassment Policy](http://geekfeminism.wikia.com/wiki/Conference_anti-harassment/Policy) and the [Wooga Code of Conduct](https://www.wooga.com/about/code-of-conduct/).
+
+Retrieved on November 22, 2016 from [http://citizencodeofconduct.org/](http://citizencodeofconduct.org/)

.github/CONTRIBUTING.md

@@ -0,0 +1,134 @@
+# How to contribute efficiently
+
+Thank you for taking the time and energy to read this file and contribute to one of the wooga libraries. All contributions are welcome. Be it bug reports, documentation updates, bug fixes or improvements. 
+
+Sections covered in this file:
+
+* [Reporting bugs or proposing features](#reporting-bugs-or-proposing-features)
+* [Contributing pull requests](#contributing-pull-requests)
+* [Communicating with other developers](#communicating-with--other-developers)
+
+**Please read the first section before reporting a bug!**
+
+## Reporting bugs or proposing features
+
+The golden rule is to **always open *one* issue for *one* bug**. If you notice several bugs and want to report them, make sure to create one new issue for each of them.
+
+Everything referred to hereafter as "bug" also applies for feature requests.
+
+If you are reporting a new issue, you will make our life much simpler (and the fix come much sooner) by following those guidelines:
+
+#### Specify the platform
+
+If you believe your issue is device/platform dependent, please specify:
+
+* Operating system
+* Platform (including architecture, e.g. x86, x86_64, arm, etc.)
+* Java version
+* gradle version
+
+#### Specify steps to reproduce
+
+Many bugs can't be reproduced unless specific steps are taken. Please **specify the exact steps** that must be taken to reproduce the condition, and try to keep them as minimal as possible.
+
+#### Use Labels
+
+Githubs label system makes it easier to search for specific issues or group them into clusters. There is a wide varity of labels already defined. 
+
+## Contributing pull requests
+
+If you want to add new engine functionalities, please make sure that:
+
+* This functionality is desired.
+* You talked to other developers on how to implement it best (on either communication channel, and maybe in a GitHub issue first before making your PR).
+* Even if it does not get merged, your PR is useful for future work by another developer.
+
+Similar rules can be applied when contributing bug fixes - it's always best to discuss the implementation in the bug report first if you are not 100% about what would be the best fix.
+
+#### Be nice to the git history
+
+Try to make simple PRs with that handle one specific topic. Just like for reporting issues, it's better to open 3 different PRs that each address a different issue than one big PR with three commits.
+
+When updating your topic branch with changes from master, please use `git pull --rebase` to avoid creating "merge commits". Those commits unnecessarily pollute the git history when coming from PRs.
+
+```bash
+git pull origin master --rebase
+```
+
+This will `fetch` the upstream changes, rewind your local checkout to the last integration point, apply the changes from remote and after that apply all your local changes.
+
+You can also set `branch.autosetuprebase` in `git-config`
+
+_from the git man page_
+```man
+-r, --rebase[=false|true|preserve]
+    When true, rebase the current branch on top of the upstream branch
+    after fetching. If there is a remote-tracking branch corresponding
+    to the upstream branch and the upstream branch was rebased since
+    last fetched, the rebase uses that information to avoid rebasing
+    non-local changes.
+
+    When preserve, also rebase the current branch on top of the
+    upstream branch, but pass --preserve-merges along to git rebase so
+    that locally created merge commits will not be flattened.
+
+    When false, merge the current branch into the upstream branch.
+
+    See pull.rebase, branch.<name>.rebase and branch.autosetuprebase in
+    git-config(1) if you want to make git pull always use --rebase
+    instead of merging.
+
+    Note
+    This is a potentially dangerous mode of operation. It rewrites
+    history, which does not bode well when you published that
+    history already. Do not use this option unless you have read
+    git-rebase(1) carefully.
+```
+
+**Pro:**
+- The history looks cleaner
+- no pull merge commits `Merge origin/master into master`
+
+**Cons:**
+- you could end up fxing merge issues multiple times (in most cases it's the fault of the first commit not correctly merged) 
+- by default the commit dates are no longer in order (there is the flag `--committer-date-is-author-date`)
+- you need to stash/unstash local changes (there is a config option `rebase.autoStash` or flag `--autostash` fot that)
+
+This git style guide has some good practices to have in mind: <https://github.com/agis-/git-style-guide>
+
+#### Format your commit logs with readability in mind
+
+The way you format your commit logs is quite important to ensure that the commit history and changelog will be easy to read and understand. A git commit log is formatted as a short title (first line) and an extended description (everything after the first line and an empty separation line).
+
+The short title is the most important part, as it is what will appear in the `shortlog` changelog (one line per commit, so no description shown) or in the GitHub interface unless you click the "expand" button. As the name tells it, try to keep that first line relatively short (ideally <= 50 chars, though it's rare to be able to tell enough in so few characters, so you can go a bit higher) - it should describe what the commit does globally, while details would go in the description. Typically, if you can't keep the title short because you have too much stuff to mention, it means that you should probably split your changes in several commits :)
+
+I could go on and on about the format and length of a good commit message. But check out this post <http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html> instead.
+
+In short:
+
+```plain
+Capitalized, short (50 chars or less) summary
+
+More detailed explanatory text, if necessary.  Wrap it to about 72 characters
+or so.  In some contexts, the first line is treated as the subject of an email
+and the rest of the text as the body.  The blank line separating the summary
+from the body is critical (unless you omit the body entirely); tools like
+rebase can get confused if you run the two together.
+
+Write your commit message in the imperative: "Fix bug" and not "Fixed bug" or 
+"Fixes bug."  This convention matches up with commit messages generated by 
+commands like git merge and git revert.
+
+Further paragraphs come after blank lines.
+
+- Bullet points are okay, too
+- Typically a hyphen or asterisk is used for the bullet, followed by a 
+  single space, with blank lines in between, but conventions vary here
+- Use a hanging indent
+
+Use markdown when possible. Exceptions are `# Headlines` 
+```
+
+Thanks!
+
+The Atlas development team

.github/ISSUE_TEMPLATE.md

@@ -0,0 +1,15 @@
+Before open a new issue check the following list.
+
+_You don't need to add this checklist to the pull request body._
+
+- [ ] check issue list if issue is already reported
+- [ ] write good issue description
+- [ ] add appropriate labels
+
+## Description
+Add short description
+
+## Steps to reproduce
+
+1. open ...
+2. ...

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,35 @@
+Before open a new pull request please check the following list.
+
+_You don't need to add this checklist to the pull request body._
+- [ ] add new tests to test your changes
+- [ ] run the tests and check that they pass
+- [ ] cleanup your commits
+- [ ] write good pull request description
+- [ ] add appropiate labels
+
+## Description
+Add short description
+
+## Changes
+* ![ADD] add new file x.cs
+* ![FIX] broken `String` in ...
+...
+
+
+
+
+[NEW]:https://resources.atlas.wooga.com/icons/icon_new.svg "New"
+[ADD]:https://resources.atlas.wooga.com/icons/icon_add.svg "Add"
+[IMPROVE]:https://resources.atlas.wooga.com/icons/icon_improve.svg "IMPROVE"
+[CHANGE]:https://resources.atlas.wooga.com/icons/icon_change.svg "Change"
+[FIX]:https://resources.atlas.wooga.com/icons/icon_fix.svg "Fix"
+[UPDATE]:https://resources.atlas.wooga.com/icons/icon_update.svg "Update"
+
+[BREAK]:https://resources.atlas.wooga.com/icons/icon_break.svg "Remove"
+[REMOVE]:https://resources.atlas.wooga.com/icons/icon_remove.svg "Remove"
+[IOS]:https://resources.atlas.wooga.com/icons/icon_iOS.svg "iOS"
+[ANDROID]:https://resources.atlas.wooga.com/icons/icon_android.svg "Android"
+[WEBGL]:https://resources.atlas.wooga.com/icons/icon_webGL.svg "WebGL"
+[UNITY]:https://resources.atlas.wooga.com/icons/icon_unity.svg "Unity"
+[GRADLE]:https://resources.atlas.wooga.com/icons/icon_gradle.svg "Gradle"
+[LINUX]:https://resources.atlas.wooga.com/icons/icon_linux.svg "Linux"

.github/SUPPORT.md

@@ -0,0 +1,5 @@
+## Communicating with other developers
+
+pullrequests for all packages.
+- [GitHub issues](https://github.com/wooga/atlas-dotnet-sonarqube/issues): All discussions around bugs, feature requests.
+- [GitHub pull requests](https://github.com/wooga/atlas-dotnet-sonarqube/pulls): All discussions bugfixes, important and new additions.

.github/dependabot.yml

@@ -0,0 +1,36 @@
+version: 2
+registries:
+  maven-repository-wooga-jfrog-io-wooga-atlas-maven:
+    type: maven-repository
+    url: https://wooga.jfrog.io/wooga/atlas-maven
+    username: atlas
+    password: "${{secrets.MAVEN_REPOSITORY_WOOGA_JFROG_IO_WOOGA_ATLAS_MAVEN_PASSWORD}}"
+
+updates:
+- package-ecosystem: gradle
+  directory: "/"
+  schedule:
+    interval: daily
+    time: "04:00"
+  open-pull-requests-limit: 10
+  ignore:
+  - dependency-name: org.spockframework:spock-core
+    versions:
+    - ">= 0"
+  - dependency-name: net.wooga.plugins
+    versions:
+    - 1.5.0
+    - 2.0.0
+  - dependency-name: com.gradle.plugin-publish
+    versions:
+    - 0.13.0
+    - 0.14.0
+  - dependency-name: com.netflix.nebula:nebula-test
+    versions:
+    - 7.10.2
+    - 8.1.0
+  - dependency-name: org.kt3k.gradle.plugin:coveralls-gradle-plugin
+    versions:
+    - 2.8.3
+  registries:
+  - maven-repository-wooga-jfrog-io-wooga-atlas-maven

src/integrationTest/groovy/wooga/gradle/dotnetsonar/SonarScannerExtensionIntegrationSpec.groovy

@@ -13,7 +13,7 @@ class SonarScannerExtensionIntegrationSpec extends PluginIntegrationSpec {
         File fakeScannerExec = SpecFakes.argReflectingFakeExecutable("sonarscanner")
         and: "custom task registering itself on sonar scanner extension"
         buildFile << """
-        ${forceAddSonarScannerObjectToExtension(fakeScannerExec)}
+        ${forceAddObjectsToExtension(fakeScannerExec)}
         ${setupSonarScannerExtension("sonarScannerExt")}
         tasks.register("custom") {
             sonarScannerExt.registerBuildTask(it)

src/integrationTest/groovy/wooga/gradle/dotnetsonar/tasks/BuildSolutionTaskIntegrationSpec.groovy

@@ -15,7 +15,7 @@ class BuildSolutionTaskIntegrationSpec extends PluginIntegrationSpec {
 
     def setup() {
         def fakeSonarScannerExec = argReflectingFakeExecutable("sonarscanner", 0)
-        buildFile << forceAddSonarScannerObjectToExtension(fakeSonarScannerExec)
+        buildFile << forceAddObjectsToExtension(fakeSonarScannerExec)
     }
 
     @Unroll

src/integrationTest/groovy/wooga/gradle/dotnetsonar/tasks/SonarScannerBeginTaskIntegrationSpec.groovy

@@ -14,7 +14,7 @@ class SonarScannerBeginTaskIntegrationSpec extends PluginIntegrationSpec {
         given: "a sonar scanner executable"
         def fakeSonarScannerExec = argReflectingFakeExecutable("sonarscanner", 0)
         and: "a set up sonar scanner extension"
-        buildFile << forceAddSonarScannerObjectToExtension(fakeSonarScannerExec)
+        buildFile << forceAddObjectsToExtension(fakeSonarScannerExec)
         and: "a configured sonarqube extension"
         def projectVersion = "0.0.1"
         buildFile << """
@@ -42,15 +42,14 @@ class SonarScannerBeginTaskIntegrationSpec extends PluginIntegrationSpec {
         given: "a failing sonar scanner executable"
         def fakeSonarScannerExec = argReflectingFakeExecutable("sonarscanner", 1)
         and: "a set up sonar scanner extension"
-        buildFile << forceAddSonarScannerObjectToExtension(fakeSonarScannerExec)
+        buildFile << forceAddObjectsToExtension(fakeSonarScannerExec)
 
         when: "running the sonarScannerBegin task"
         def result = runTasksWithFailure("sonarScannerBegin")
 
         then: "should fail on execution with non-zero exit value"
         def e = rootCause(result.failure)
         e.getClass().name == ExecException.name
-        e.message.contains(fakeSonarScannerExec.absolutePath)
         e.message.contains("exit value 1")
     }
 }

src/integrationTest/groovy/wooga/gradle/dotnetsonar/tasks/SonarScannerEndTaskIntegrationSpec.groovy

@@ -14,7 +14,7 @@ class SonarScannerEndTaskIntegrationSpec extends PluginIntegrationSpec {
         and: "a sonar scanner executable"
         def fakeSonarScannerExec = argReflectingFakeExecutable("sonarscanner", 0)
         and: "a set up sonar scanner extension"
-        buildFile << forceAddSonarScannerObjectToExtension(fakeSonarScannerExec)
+        buildFile << forceAddObjectsToExtension(fakeSonarScannerExec)
         and: "a configurated sonarqube extension"
         def loginToken = "loginToken"
         buildFile << """
@@ -39,15 +39,14 @@ class SonarScannerEndTaskIntegrationSpec extends PluginIntegrationSpec {
         given: "a failing sonar scanner executable"
         def fakeSonarScannerExec = argReflectingFakeExecutable("sonarscanner", 1)
         and: "a set up sonar scanner extension"
-        buildFile << forceAddSonarScannerObjectToExtension(fakeSonarScannerExec)
+        buildFile << forceAddObjectsToExtension(fakeSonarScannerExec)
 
         when: "running the sonarScannerEnd task"
         def result = runTasksWithFailure("sonarScannerEnd")
 
         then: "should fail on execution with non-zero exit value"
         def e = rootCause(result.failure)
         e.getClass().name == ExecException.name
-        e.message.contains(fakeSonarScannerExec.absolutePath)
         e.message.contains("exit value 1")
     }