feedback-to-code/mozzarella huggingface dataset:
Repository: mockito/mockito
Issue: Travis builds from non-core developers fail on assertEnvVariables
Labels: bug
continuous integration

Example build: https://travis-ci.org/mockito/mockito/jobs/188911380

Seems that this does not affect core developers, as my build has been succesful: https://travis-ci.org/mockito/mockito/builds/188321204 as well as those in #865 and #859

Issue comments:
I think the easiest solution is to not assert the GH_TOKEN if the build is a pull request
Can't we just disable the checks if the repo is not mockito/mockito ?
Pull requests always have `mockito/mockito` as repository?
No only ours, external contributors have a fork. Since the GH_TOKEN assertion don't fail for our pull request I think this is safe assumption.
@szczepiq could you make this high priority on your list? Failing builds discourages external developers from publishing their work

Pull request review comments:

Patch that resolved the issue:
diff --git a/gradle/root/release.gradle b/gradle/root/release.gradle
index 44d938bc72..821070ff99 100644
--- a/gradle/root/release.gradle
+++ b/gradle/root/release.gradle
@@ -254,10 +254,10 @@ task pushChanges(type: Exec) {
 }
 
 releaseWorkflow {
-    step assertEnvVariables
-    step assertCleanWorkingCopy
     step releaseNeeded
     onlyIf { releaseNeeded.needed }
+    step assertEnvVariables
+    step assertCleanWorkingCopy
     step bintrayUploadAll //TODO make upload task the very last task or very close to push so that the most invasive steps go last
     step pullCommits
     step configureGenericGitUser, [cleanup: restoreGitUser]


Test patch:
Repository: mockito/mockito
Issue: Upgrading to Objenesis 2.5
Labels: java-9

Mockito already uses Objenesis 2.4.
However Objenesis 2.5 was just released and supports the latest [JDK 9 build 151 jigsaw](http://objenesis.org/notes.html)

Issue comments:

Pull request review comments:

Patch that resolved the issue:
diff --git a/build.gradle b/build.gradle
index 2eac447f58..7b9b8da4a3 100644
--- a/build.gradle
+++ b/build.gradle
@@ -49,7 +49,7 @@ dependencies {
     compile 'net.bytebuddy:byte-buddy-agent:1.6.2'
 
     provided "junit:junit:4.12", "org.hamcrest:hamcrest-core:1.3"
-    compile "org.objenesis:objenesis:2.4"
+    compile "org.objenesis:objenesis:2.5"
 
     testCompile 'org.ow2.asm:asm:5.1'
 
@@ -91,4 +91,4 @@ release.mustRunAfter ciBuild //Making sure that release task is only invoked aft
 buildScan {
     licenseAgreementUrl = 'https://gradle.com/terms-of-service'
     licenseAgree = 'yes'
-}
\ No newline at end of file
+}
diff --git a/gradle/mockito-core/osgi.gradle b/gradle/mockito-core/osgi.gradle
index 05d99eec94..2b0eb65fee 100644
--- a/gradle/mockito-core/osgi.gradle
+++ b/gradle/mockito-core/osgi.gradle
@@ -20,7 +20,7 @@ afterEvaluate {
                     'junit.*;resolution:=optional',
                     'org.junit.*;resolution:=optional',
                     'org.hamcrest;resolution:=optional',
-                    'org.objenesis;version="[2.4,3.0)"',
+                    'org.objenesis;version="[2.5,3.0)"',
                     'org.mockito.*'
 
             instruction 'Private-Package',


Test patch:
Repository: mockito/mockito
Issue: Documentation missing clarification for consecutive stubbing
Labels: docs

The [documentation](https://static.javadoc.io/org.mockito/mockito-core/2.6.3/org/mockito/Mockito.html#10) for consecutive stubbing is missing a clarification.

When multiple when/thenReturn statements are being used instead of chaining .thenReturn() statements, each stubbing overrides the existing one.




Issue comments:
I am going to submit a Pull Request, adding an additional clarification with code example in the docs.

Pull request review comments:
I'd rephrase to : 

```
<strong>Warning</strong> : if instead of chaining {@code .thenReturn()} calls, multiple stubbing with same matchers or arguments are used then each stubbing will override the previous one :
```
Sure, sounds much better. I'm going to update the PR to this.

Patch that resolved the issue:
diff --git a/src/main/java/org/mockito/Mockito.java b/src/main/java/org/mockito/Mockito.java
index 228997d4b0..27f0768054 100644
--- a/src/main/java/org/mockito/Mockito.java
+++ b/src/main/java/org/mockito/Mockito.java
@@ -452,6 +452,16 @@
  *   .thenReturn("one", "two", "three");
  * </code></pre>
  *
+ * <strong>Warning</strong> : if instead of chaining {@code .thenReturn()} calls, multiple stubbing with the same matchers or arguments
+ * is used, then each stubbing will override the previous one:
+ *
+ * <pre class="code"><code class="java">
+ * //All mock.someMethod("some arg") calls will return "two"
+ * when(mock.someMethod("some arg"))
+ *   .thenReturn("one")
+ * when(mock.someMethod("some arg"))
+ *   .thenReturn("two")
+ * </code></pre>
  *
  *
  *


Test patch:
Repository: mockito/mockito
Issue: Add editor configuration to ease the process of adhering to Checkstyle

We recently added the enforcement of Checkstyle. @ChristianSchwarz requested in https://github.com/mockito/mockito/pull/908#issuecomment-281468837 to also include a default template or at least provide steps for developers to automatically adhere to the style guide. E.g. no manual labor required, the IDE fixes it for the contributor.

We can probably adopt [EditorConfig](http://editorconfig.org/) which is automatically supported by IntelliJ and there is a plugin available for Eclipse users. There is even [support by GitHub themselves](https://github.com/editorconfig/editorconfig.github.com/pull/48).

Issue comments:

Pull request review comments:
I'll also add : 

```
charset=utf-8
```


I've met in some placed that option disabled for markdown files:

```
[*.md]
trim_trailing_whitespace = false
```

However, I'm not sure if it was a copy-paste from one source or there is a valid use case where new whitespace in a markdown files is required.
yup, for Eclipse guys on Windows.
We can always improve this file.

Regarding the specific change for md files, I don't think trailing spaces should be an issue.

Patch that resolved the issue:
diff --git a/.editorconfig b/.editorconfig
new file mode 100644
index 0000000000..88fd9c2e0b
--- /dev/null
+++ b/.editorconfig
@@ -0,0 +1,8 @@
+root = true
+
+[*]
+end_of_line = lf
+insert_final_newline = true
+trim_trailing_whitespace = true
+indent_style = space
+indent_size = 4
diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md
index 13884c3a1e..f08d2c21b2 100644
--- a/.github/CONTRIBUTING.md
+++ b/.github/CONTRIBUTING.md
@@ -78,6 +78,10 @@ But first of all, make sure that :
 * Line ending character is unix-style **`LF`**
 * New line is added at end of file: `IntelliJ setting > Editor > General > Ensure line feed at file end on save`
 
+For most editors, this should be automatically enforced by [EditorConfig](http://editorconfig.org/).
+Check if your editor has a built-in plugin or if you need to download one.
+IntelliJ has a built-in plugin, for Eclipse you need to download [this plugin](https://github.com/ncjones/editorconfig-eclipse#readme).
+
 ### Imports
 
 Imports must be sorted in the following order


Test patch:
Repository: mockito/mockito
Issue: Update documentation about mockito-inline artifact
Labels: please contribute

Mockito documentation currently does not explain "mockito-inline" artifact that is used for inline mocking (mocking finals). The main Mockito class still contains information on how to configure the inline mocking using a classpath resource.

Issue comments:

Pull request review comments:

Patch that resolved the issue:
diff --git a/src/main/java/org/mockito/Mockito.java b/src/main/java/org/mockito/Mockito.java
index 5e74aa7790..f886627f56 100644
--- a/src/main/java/org/mockito/Mockito.java
+++ b/src/main/java/org/mockito/Mockito.java
@@ -36,6 +36,7 @@
  * <b>
  *      <a href="#0">0. Migrating to Mockito 2</a><br/>
  *      <a href="#0.1">0.1 Mockito Android support</a></br/>
+ *      <a href="#0.2">0.2 Configuration-free inline mock making</a></br/>
  *      <a href="#1">1. Let's verify some behaviour! </a><br/>
  *      <a href="#2">2. How about some stubbing? </a><br/>
  *      <a href="#3">3. Argument matchers </a><br/>
@@ -110,6 +111,25 @@
  * <a href="https://github.com/mockito/mockito/issues/new">on the official issue tracker</a>.
  * Do provide the version of Android you are working on and dependencies of your project.
  *
+ * <h3 id="0.2">0.2. <a class="meaningful_link" href="#mockito-inline" name="mockito-inline">Configuration-free inline mock making</a></h3>
+ *
+ * Starting with version 2.7.6, we offer the 'mockito-inline' artifact that enables <a href="#39">inline mock making</a> without configuring
+ * the MockMaker extension file. To use this, add the `mockito-inline` instead of the `mockito-core` artifact as follows:
+ *
+ * <pre class="code"><code>
+ * repositories {
+ *   jcenter()
+ * }
+ * dependencies {
+ *   testCompile "org.mockito:mockito-inline:+"
+ * }
+ * </code></pre>
+ *
+ * Be aware that this artifact may be abolished when the inline mock making feature is integrated into the default mock maker.
+ *
+ * <p>
+ * For more information about inline mock making, see <a href="#39">section 39</a>.
+ *
  * <h3 id="1">1. <a class="meaningful_link" href="#verification" name="verification">Let's verify some behaviour!</a></h3>
  *
  * The following examples mock a List, because most people are familiar with the interface (such as the


Test patch:
Repository: mockito/mockito
Issue: Release automation endless loop issue
Labels: continuous integration

Recently I introduced a problem (PR: https://github.com/mockito/mockito/pull/1057) that created endless loop with our releases. Fallout / clean up needed:
 - [x] - stop the endless loop by reverting the commit. Thank you @TimvdLippe spotting the issue and reverting the change!
 - [x] - remove unnecessary tags
 - [x] - discard versions/artifacts that were pushed to Bintray (not "published" yet, safe to delete)
 - [x] - delete unnecessary content from [release notes file](https://github.com/mockito/mockito/blob/release/2.x/doc/release-notes/official.md)
 - [x] - fix the bug in release automation code, pr submitted, waiting for review & merge: https://github.com/mockito/mockito-release-tools/pull/103
 - [x] - test & reapply PR #1057

Issue comments:
Waiting for review / merge: https://github.com/mockito/mockito-release-tools/pull/103
Fix seems fine to me. Have not executed it locally though.
I don't know if this is related, but the release process currently [fails](https://travis-ci.org/mockito/mockito/jobs/230865593#L796) with:
> remote: Invalid username or password.

on a git push.
It is sadly unrelated. It seems that @szczepiq password was reset for some reason :sob: 
There is something weird going on with GitHub auth tokens. They seem to be expiring or something. I've tested locally a new token, updated Travis configuration and restarted Travis Job. We'll see if it helps.
It was fixed!

Pull request review comments:

Patch that resolved the issue:
diff --git a/gradle.properties b/gradle.properties
index efadf69c1a..6d27b51dde 100644
--- a/gradle.properties
+++ b/gradle.properties
@@ -2,4 +2,4 @@ org.gradle.daemon=true
 org.gradle.parallel=true
 
 #Declared the dependency here to avoid duplication across build.gradle files
-dependencies.mockito-release-tools=gradle.plugin.org.mockito:mockito-release-tools:0.8.0
+dependencies.mockito-release-tools=gradle.plugin.org.mockito:mockito-release-tools:0.8.1


Test patch:
Repository: mockito/mockito
Issue: Javadoc Example Throws Unexpected Exception
Labels: docs
please contribute

 Verify(mockedList, atLeast(2)).add("five times"); - would throw
org.mockito.exceptions.verification.TooLittleActualInvocations

Correcting this would help to make sure new devs are not confused by the verify use case there.

<img width="678" alt="screen shot 2017-05-17 at 8 40 03 pm" src="https://cloud.githubusercontent.com/assets/10499046/26181818/2241904c-3b41-11e7-8f71-6974d46d5579.png">


Issue comments:
What would you consider to be the correct behaviour here? At a push I might propose a slight change in naming to "TooFewActualInvocations" but the core behaviour is the same.

Your example is confusing because your "atLeast(2)" verification is on .add("five times"), which suggests five invocations of add() with that String, but there are no invocations with that String.

What do you expect to see here?
I think the expectation is that the code works when it is copy pasted to IDE and executed. Why don't we fix it by changing "five times" to "three times"? Do you want to contribute? Please do! :)
Oh wait, I see now. It's a problem with [the documentation](http://static.javadoc.io/org.mockito/mockito-core/2.8.9/org/mockito/Mockito.html#4). Sure thing, I can update that no problem.
Thanks folks. 

Pull request review comments:

Patch that resolved the issue:
diff --git a/src/main/java/org/mockito/Mockito.java b/src/main/java/org/mockito/Mockito.java
index cd4955a63d..8f389455cf 100644
--- a/src/main/java/org/mockito/Mockito.java
+++ b/src/main/java/org/mockito/Mockito.java
@@ -293,7 +293,7 @@
  *
  * //verification using atLeast()/atMost()
  * verify(mockedList, atLeastOnce()).add("three times");
- * verify(mockedList, atLeast(2)).add("five times");
+ * verify(mockedList, atLeast(2)).add("three times");
  * verify(mockedList, atMost(5)).add("three times");
  *
  * </code></pre>


Test patch:
Repository: mockito/mockito
Issue: No release build for 2.8.39 - possible bug in Travis CI
Labels: bug
continuous integration

For some reason, Travis CI did not trigger the main build for version 2.8.39. In the travis dashboard for that build I can see only [3 child jobs](https://travis-ci.org/mockito/mockito/builds/237813636) whereas normally there are [4 child jobs](https://travis-ci.org/mockito/mockito/builds/237433149).

@szpak, have you seen something like that before? I'm restarting the build, let's see what happens :)

Issue comments:
No, I haven't seen anything like that before. There were no changes in .travis.yml and I have no idea what one of the jobs is missing. Probably (I hope) it will be automatically fixed by the next commit. It may be good to report it to Travis.
Just merged another PR, will see how many child jobs Travis triggers this time :)
Another instance of this problem. I've contacted Travis CI support, put you guys on cc.
Commented on the ticket in Travis issue tracker (https://github.com/travis-ci/travis-ci/issues/4681#issuecomment-306102865). Here's the message from Travis CI support:

```
Thanks for reaching out and I'm sorry for this change in behavior.

This is the result of a change we released 3 days ago and it's detailed here: https://github.com/travis-ci/travis-ci/issues/4681. In brief, if you have no matrix expansion on the top level, and there is at least one job defined in `matrix.include`, the top level job is no longer included in the build matrix.

You should be able to get your old build configuration back by adding the following under `matrix.include`:


matrix:
  include:
  - jdk: oraclejdk7
  - jdk: oraclejdk7
    env: SKIP_RELEASE=true MOCK_MAKER=mock-maker-inline
  ⋮
```

I'm trying it now ;)

Pull request review comments:

Patch that resolved the issue:
diff --git a/.travis.yml b/.travis.yml
index 7f4507d163..88d3f36acf 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -25,11 +25,9 @@ before_install:
   - export TRAVIS_COMMIT_MESSAGE=$(git log --format=%B -n 1 $TRAVIS_COMMIT)
   - echo "$TRAVIS_COMMIT_MESSAGE"
 
-jdk:
-  - oraclejdk7
-
 matrix:
   include:
+  - jdk: oraclejdk7
   - jdk: oraclejdk7
     env: SKIP_RELEASE=true MOCK_MAKER=mock-maker-inline
   - jdk: oraclejdk8


Test patch:
Repository: mockito/mockito
Issue: Version not released to Maven Central
Labels: question
continuous integration

2 days ago I requested a [build](https://github.com/mockito/mockito/commit/04961ae3cc8093916f563d7edc223224d757a4a1) with Maven Central sync (having notable changes merged). Looking into release configuration I used `[ci maven-central-release]` and it seems to be [enabled](https://travis-ci.org/mockito/mockito/jobs/242215132#L842) in Travis.

However, that release is not [available](https://maven-badges.herokuapp.com/maven-central/org.mockito/mockito-core) in Maven Central (2.8.9 is the newest as time of raising this issue instead of 2.8.44).

@szczepiq Is there anything else (with the current release mechanism) that is needed to do to build a "notable version"?

Issue comments:
I think we need to set a property on our project, looking at the line above in the Travis build you linked: 
```
project property 'maven-central-release' exists: false
```
Looking! Thank you for reporting!
Great bug report guys! It was very easy to nail down the issue!
Please review / merge: https://github.com/mockito/mockito/pull/1129
Worked perfectly - https://repo1.maven.org/maven2/org/mockito/mockito-core/2.8.47/

Pull request review comments:
👍 

Patch that resolved the issue:
diff --git a/gradle/shipkit.gradle b/gradle/shipkit.gradle
index 24ac169368..2c9efd7e35 100644
--- a/gradle/shipkit.gradle
+++ b/gradle/shipkit.gradle
@@ -84,4 +84,5 @@ static boolean shouldReleaseToCentral(project) {
     project.afterEvaluate {
         project.tasks.performRelease.doLast { logger.lifecycle(message) }
     }
+    return centralRelease
 }


Test patch:
Repository: mockito/mockito
Issue: Unnecessary release was triggered
Labels: bug
continuous integration

It seems that Shipkit was not able to avoid unnecessary release (see the [release notes](https://github.com/mockito/mockito/blob/release/2.x/doc/release-notes/official.md)). I will look into that. Our goal is not avoid shipping new version if binaries don't change.

Issue comments:
This should be fixed now.

Pull request review comments:

Patch that resolved the issue:
diff --git a/gradle.properties b/gradle.properties
index d7832b247d..946ba4c5d3 100644
--- a/gradle.properties
+++ b/gradle.properties
@@ -2,4 +2,4 @@ org.gradle.daemon=true
 org.gradle.parallel=true
 
 #Declared the dependency here to avoid duplication across build.gradle files
-dependencies.shipkit=org.shipkit:shipkit:0.8.112
+dependencies.shipkit=org.shipkit:shipkit:0.8.114


Test patch:
Repository: mockito/mockito
Issue: Travis CI ERROR: JAVA_HOME is set to an invalid directory
Labels: continuous integration

Travis CI builds started failing with "ERROR: JAVA_HOME is set to an invalid directory: /usr/lib/jvm/java-7-oracle". [Example failure](https://travis-ci.org/mockito/mockito/jobs/270842998).

```
$ ./gradlew build idea -s -PcheckJava6Compatibility && ./gradlew ciPerformRelease
ERROR: JAVA_HOME is set to an invalid directory: /usr/lib/jvm/java-7-oracle
Please set the JAVA_HOME variable in your environment to match the
location of your Java installation.
```

It looks like there was some incompatible change rolled out in Travis CI.

Issue comments:
This was fixed in #1184

Pull request review comments:

Patch that resolved the issue:
diff --git a/.travis.yml b/.travis.yml
index e626d42d1a..096880fcb6 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -15,11 +15,7 @@ language: java
 
 matrix:
   include:
-  - jdk: oraclejdk7
-  - jdk: oraclejdk7
-    env: SKIP_RELEASE=true MOCK_MAKER=mock-maker-inline
   - jdk: oraclejdk8
-    env: SKIP_RELEASE=true
   - jdk: oraclejdk8
     env: SKIP_RELEASE=true MOCK_MAKER=mock-maker-inline
 


Test patch:
Repository: mockito/mockito
Issue: JDK9: set a stable module name with `Automatic-Module-Name` entry in MANIFEST
Labels: java-9
please contribute

JDK9 is out and introduces a module system.

Mockito does not currently use modules. When we use it in a JDK9 modular application, Java turns the JAR into a so-called automatic module, whose name is derived from the JAR archive name (*mockito*, in this case). However, the default name does not follow the recommended module naming conventions (reverse-dns style, module name derived from the main exported package).

It is possible to specify a stable automatic module name through a `Automatic-Module-Name` manifest entry, while still targeting JDK8:

```
Automatic-Module-Name: org.mockito
```

Selecting a stable module name is very important, because Java does not allow two modules to own the same package, and you may end up with a module hell. The naming issues are well-explained on Stephen Colebourne's blog:

 * http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html
 * http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html <- the explanation of module hell problem

And the comment of Mike Reinhold, chief Java architect:

> Strongly recommend that all modules be named according to the reverse Internet domain-name convention. A module's name should correspond to the name of its principal exported API package, which should also follow that convention. If a module does not have such a package, or if for legacy reasons it must have a name that does not correspond to one of its exported packages, then its name should at least start with the reversed form of an Internet domain with which the author is associated.

Issue comments:
If we can make this work on JDK6-8, I am all for it. If you can, please submit a PR that we can review :)
This change is compatible with JDK6-8, because you only add an entry to `MANIFEST.mf` file. Older Java versions simply ignore it, and JDK9 uses it as a stable automatic module name (instead of generating it from JAR archive name).

If you drop the support for older JDKs somewhere in the future, you can create a true module with the same name and the change will be invisible to JDK9 modular applications:

```java
module org.mockito {
   requires ...;
}
```

PR -> I'd love to, but I'm tracking the Jigsaw support in more projects and I'm afraid I don't have enough time to update them all. So I will see.

Pull request review comments:

Patch that resolved the issue:
diff --git a/gradle/mockito-core/osgi.gradle b/gradle/mockito-core/osgi.gradle
index 2b0eb65fee..90a32eb6f8 100644
--- a/gradle/mockito-core/osgi.gradle
+++ b/gradle/mockito-core/osgi.gradle
@@ -27,6 +27,8 @@ afterEvaluate {
                     'org.mockito.*'
 
             instruction '-removeheaders', 'Private-Package'
+
+            attributes 'Automatic-Module-Name': 'org.mockito'
         }
     }
 }


Test patch: