feedback-to-code/mozzarella huggingface dataset:
Repository: mockito/mockito
Issue: Update to org.objenesis 3.x
Labels: please contribute

Hi all,

we are slowly updating our product to Java 11; we've managed to move to Java 11 runtime, now we are trying to also compile with Java 11.

We ran into a problem with `org.easymock` (it doesn't work with Java 11 compiled classes, https://github.com/easymock/easymock/issues/218). The problem is resolved in 4.x versions.

Unfortunately, 4.x versions of `org.easymock` run only with `org.objenesis` 3.x, which `mockito` so far does not accept (upper bound for `org.objenesis` is 2.6).

Are there plans to update `mockito` to run with `org.objenesis` and if so are there known timelines?

Some more background:

We essentially wished to update to latest `mockito` and `easymock` earlier (during the Java 11 runtime move), but were unable to do so due to conflicting `org.objenesis` requirements. If we want to compile with Java 11 however, we are made to choose between  `easymock` or `mockito`, or waiting. We would prefer to wait, if a `mockito` update that runs with `org.objenesis` 3.x would be available soon.

Sorry if this should be an e-mail message and not an issue in the tracker, or if this is a duplicate (I didn't find much about `org.objenesis` in the issue list).

Best regards and thanks,
Simeon

Issue comments:
I would be happy to review a PR that updates our version of Objenesis 😄 
I'll check the contribution guide, though I can't promise much. So far Java 11 compile is not top priority in my team.

Pull request review comments:

Patch that resolved the issue:
diff --git a/gradle/dependencies.gradle b/gradle/dependencies.gradle
index d089c4d73d..9ae3679927 100644
--- a/gradle/dependencies.gradle
+++ b/gradle/dependencies.gradle
@@ -25,8 +25,7 @@ libraries.errorproneTestApi = "com.google.errorprone:error_prone_test_helpers:${
 
 libraries.autoservice = "com.google.auto.service:auto-service:1.0-rc5"
 
-// objenesis 3.x with full Java 11 support requires Java 8, bump version when Java 7 support is dropped
-libraries.objenesis = 'org.objenesis:objenesis:2.6'
+libraries.objenesis = 'org.objenesis:objenesis:3.1'
 
 libraries.asm = 'org.ow2.asm:asm:7.0'
 
diff --git a/gradle/mockito-core/osgi.gradle b/gradle/mockito-core/osgi.gradle
index 41f1902b45..a18942589d 100644
--- a/gradle/mockito-core/osgi.gradle
+++ b/gradle/mockito-core/osgi.gradle
@@ -22,7 +22,7 @@ jar {
                 'junit.*;resolution:=optional',
                 'org.junit.*;resolution:=optional',
                 'org.hamcrest;resolution:=optional',
-                'org.objenesis;version="[2.5,3.0)"',
+                'org.objenesis;version="[3.1,4.0)"',
                 'org.opentest4j.*;resolution:=optional',
                 'org.mockito.*'
         ].join(','),


Test patch:
Repository: mockito/mockito
Issue: Issue with Bundle-Version manifest header when used in Eclipse PDE development

The MANIFEST.MF currently contains e.g.: `Bundle-version: 3.6.0`

Due to the lowercase 'v' this appears to not be properly recognised by Eclipse PDE so is giving me errors on min versioned require bundle directives.

The standard headers at  https://www.osgi.org/bundle-headers-reference/ define it as `Bundle-Version` (capital V).

After a small amount of research it looks like OSGi specification possibly does accept case insensitive headers but haven't found definitive source.

In any case, changing it would keep it consistant with the other headers.

Issue comments:
Seems like we hit this issue after we fixed an initial typo in #2070. Do you mind sending a PR to change it to a capital V?
Done, thanks for quick response!

Pull request review comments:

Patch that resolved the issue:
diff --git a/gradle/mockito-core/osgi.gradle b/gradle/mockito-core/osgi.gradle
index cdee44287b..f44ea9c18b 100644
--- a/gradle/mockito-core/osgi.gradle
+++ b/gradle/mockito-core/osgi.gradle
@@ -14,7 +14,7 @@ jar {
     bnd(
         'Bundle-Name': 'Mockito Mock Library for Java. Core bundle requires Byte Buddy and Objenesis.',
         'Bundle-SymbolicName': 'org.mockito.mockito-core',
-        'Bundle-version': project.version.replace('-', '.'),
+        'Bundle-Version': project.version.replace('-', '.'),
         '-versionpolicy': '[${version;==;${@}},${version;+;${@}})',
         'Export-Package': "!org.mockito.internal.*,org.mockito.*;version=${version}",
         'Import-Package': [


Test patch:
Repository: mockito/mockito
Issue: Implement [ci skip release] in the CI pipeline
Labels: continuous integration

Make it possible to skip release when pushing changes to the repo. Our README.md currently documents that we can skip releases by adding "ci skip release" keyword to the commit message.

Reference example: https://github.com/shipkit/shipkit-auto-version/commit/7a8ada573e3d8f183b9101b716a261612db30f87

Issue comments:

Pull request review comments:

Patch that resolved the issue:
diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index d8a3b831f6..db9a46240d 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -1,3 +1,10 @@
+#
+# CI build that assembles artifacts and runs tests.
+# If validation is successful this workflow releases from the main dev branch.
+#
+# - skipping CI: add [skip ci] to the commit message
+# - skipping release: add [skip release] to the commit message
+#
 name: CI
 
 on:
@@ -14,6 +21,7 @@ jobs:
   #
   build:
     runs-on: ubuntu-latest
+    if: "! contains(toJSON(github.event.commits.*.message), '[skip ci]')"
     
     # Definition of the build matrix
     strategy:
@@ -61,10 +69,15 @@ jobs:
   # Release job, only for pushes to the main development branch
   #        
   release:
-    runs-on: ubuntu-latest
+    runs-on: ubuntu-latest    
     needs: [build] # build job must pass before we can release
-    if: github.event_name == 'push' && github.ref == 'refs/heads/release/3.x'
+    
+    if: github.event_name == 'push' 
+        && github.ref == 'refs/heads/release/3.x'
+        && !contains(toJSON(github.event.commits.*.message), '[skip release]')
+    
     steps:
+   
     - name: Check out code
       uses: actions/checkout@v2 # https://github.com/actions/checkout
       with:


Test patch:
Repository: mockito/mockito
Issue: Consider reducing CI execution footprint
Labels: continuous integration

Right now we are running CI for:
 - branch pushes
 - PRs

This causes redundant builds to be triggered (example, see actions triggered for PR #2096). Redundant builds clutter the UI (reducing dev experience) and may count against our quota of free open source builds. This issue has been discussed on GH before: https://github.community/t/how-to-trigger-an-action-on-push-or-pull-request-but-not-both/16662

Potential solutions:
 - run only on PRs and pushes the the main dev branch
 - use https://github.com/marketplace/actions/skip-duplicate-actions (adds complexity to the workflow and requires exposing secrets to yet another 3rd party code)


Issue comments:

Pull request review comments:

Patch that resolved the issue:
diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index db9a46240d..bf41083077 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -9,7 +9,7 @@ name: CI
 
 on:
   push:
-    branches: ['**']
+    branches: ['release/3.x']
     tags-ignore: [v*] # release tags are automatically generated after a successful CI build, no need to run CI against them
   pull_request:
     branches: ['**']


Test patch:
Repository: mockito/mockito
Issue: JarInputStream fails to get Manifest from published mockito-core
Labels: please contribute
build

Using mockito-core in a JPMS based gradle build fails due to a known but odd behaviour of JarInputStream. The latter only provides access to the Jar's manifest if it is the 1st or 2nd entry in the Jar. As discussed in:

* https://bugs.openjdk.java.net/browse/JDK-8031748
* https://bugs.openjdk.java.net/browse/JDK-8211917

As gradle uses the JarInputStream to get the manifest and to determine whether the Automatic-Module-Name attribute is set, it fails to add mockito-core to the module path (see GRADLE [#15270](https://github.com/gradle/gradle/issues/15270). Same issue was observed for Quarkus [#5399](https://github.com/quarkusio/quarkus/issues/5399). The attached example code [example.zip](https://github.com/mockito/mockito/files/5585881/example.zip) shows this issue.

An optimal solution would be to make sure the manifest file is kept at the Jar's beginning during the publication process.

Used versions:
* mockito-core-3.6.0.jar
* java version "11.0.6" 2020-01-14 LTS 
Java(TM) SE Runtime Environment 18.9 (build 11.0.6+8-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.6+8-LTS, mixed mode)


Issue comments:
@mockitoguy might be able to provide more insight, but I think we create our Jar on this line: https://github.com/mockito/mockito/blob/78b22fcf814c33e87585afed387cd9db0b6d36a5/gradle/java-publication.gradle#L32

We would welcome PRs for this issue. Hopefully the link provides enough context to figure out how to resolve the problem?
The commit message for fde5abb includes [ci maven-central-release] - should this cause a release to be published to maven central?
I can't see a new release there at the moment, not sure if there is usually a delay?
It should have, but it seems like it incorrectly concluded it didn't include the message. Filed #2110
On it.

Pull request review comments:

Patch that resolved the issue:
diff --git a/gradle/mockito-core/osgi.gradle b/gradle/mockito-core/osgi.gradle
index f44ea9c18b..2fa0b78354 100644
--- a/gradle/mockito-core/osgi.gradle
+++ b/gradle/mockito-core/osgi.gradle
@@ -71,7 +71,8 @@ class RemoveOsgiLastModifiedHeader {
 
             this.artifact
                 .entries()
-                .sort { it.name }
+                // Keep META-INF folder at the beginning to avoid https://github.com/mockito/mockito/issues/2108
+                .sort { (it.name.startsWith("META-INF") ? "A/" + it.name : "B/" + it.name) }
                 .each { JarEntry entry ->
 
                     stream.putNextEntry(newJarEntry(entry))


Test patch:
Repository: mockito/mockito
Issue: Release process misses commit message tag
Labels: bug
continuous integration

https://github.com/mockito/mockito/runs/1447478222#step:4:168

https://github.com/mockito/mockito/commit/fde5abb9f044a6b614eeb6a8c63d25fffe2df210 did contain `[ci maven-central-release]` and therefore should have published.

Issue comments:
on it
Should work now and there is a version in maven central: https://bintray.com/mockito/maven/mockito/3.6.28#central

Pull request review comments:

Patch that resolved the issue:
diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index b67cd75e35..236a08feab 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -91,5 +91,6 @@ jobs:
     - name: Build and publish
       run: ./gradlew bintrayUpload githubRelease --scan
       env:
+        MAVEN_CENTRAL_RELEASE: ${{contains(toJSON(github.event.commits.*.message), '[ci maven-central-release]')}}
         GH_WRITE_TOKEN: ${{secrets.GH_WRITE_TOKEN}}
         BINTRAY_API_KEY: ${{secrets.BINTRAY_API_KEY}}
diff --git a/gradle/shipkit.gradle b/gradle/shipkit.gradle
index 1dd2f1cc23..2a430fe6f8 100644
--- a/gradle/shipkit.gradle
+++ b/gradle/shipkit.gradle
@@ -28,7 +28,7 @@ ext.mavenCentralRelease = shouldReleaseToCentral(project)
  * To test this logic, run build with '-i' (info logging) and inspect the build output.
  */
 static boolean shouldReleaseToCentral(project) {
-    boolean centralReleaseByCommit = System.getenv("TRAVIS_COMMIT_MESSAGE")?.contains("[ci maven-central-release]")
+    boolean centralReleaseByCommit = 'true' == System.getenv("MAVEN_CENTRAL_RELEASE")
     boolean centralReleaseByProjectProperty = project.hasProperty("maven-central-release")
     boolean centralRelease = centralReleaseByCommit || centralReleaseByProjectProperty
     def message = """Bintray publish was using following settings:


Test patch:
Repository: mockito/mockito
Issue: Mockito published maven artifact is missing .module files

Around Gradle 5.3 new Gradle metadata was introduced (see https://docs.gradle.org/current/userguide/publishing_gradle_module_metadata.html) This allows Gradle builds to publish more detail about dependencies than the lagacy maven pom.

Mockito is generating those files, but they aren't getting uploaded to Maven Central see: https://repo1.maven.org/maven2/org/mockito/mockito-junit-jupiter/3.6.28/

However in the [pom.xml](https://repo1.maven.org/maven2/org/mockito/mockito-junit-jupiter/3.6.28/mockito-junit-jupiter-3.6.28.pom) it contains the comment that tells Gradle to check for the `.module` files:

```
<!--
 This module was also published with a richer model, Gradle metadata,  
-->
<!--
 which should be used instead. Do not delete the following line which  
-->
<!--
 is to indicate to Gradle or any Gradle module metadata file consumer  
-->
<!-- that they should prefer consuming it instead. -->
<!-- do_not_remove: published-with-gradle-metadata -->
```

## Solution 1 [Disable metadata](https://docs.gradle.org/current/userguide/publishing_gradle_module_metadata.html#sub:disabling-gmm-publication ): 

This will remove the comment from the pom.xml and so Gradle won't continue to check for the `.module` file.

```
    tasks.withType<GenerateModuleMetadata> {
        enabled = false
    }
```

## Solution 2- Update the maven publishing to include the missing files

This is the better long-term solution. However I don't have a direct recommendation since I don't have experience in that regard and don't know what is mis-configured.


## Why hasn't this been a problem before?

When using `mavenCentral()` as a repo directly, it serves up a 404 for the missing `.module` file and Gradle recovers fine. However when using an internal repository like Artifactory, it is common to configure it to return `403` for missing files to try to obscure data that shouldn't be accessible.

So to reproduce this you would need to use Gradle > 5.3, Using Mockito as a dependency, when using a locked down Maven repository that is configured to serve 403 instead of exposing 404 for missing artifacts.

Issue comments:

Pull request review comments:

Patch that resolved the issue:
diff --git a/gradle/java-publication.gradle b/gradle/java-publication.gradle
index e7e03d444c..9fa7d62a5c 100644
--- a/gradle/java-publication.gradle
+++ b/gradle/java-publication.gradle
@@ -25,6 +25,10 @@ artifacts {
     archives javadocJar
 }
 
+tasks.withType(GenerateModuleMetadata) {
+    enabled = false
+}
+
 //Gradle Maven publishing plugin configuration (https://docs.gradle.org/current/userguide/publishing_maven.html)
 apply plugin: "maven-publish"
 publishing {


Test patch:
Repository: mockito/mockito
Issue: Feature request: Unify order of parameters
Labels: please contribute

Hello,

I just stumbled accross the switched order of the VerificationMode parameter

    org.mockito.Mockito.verify(T, VerificationMode)
vs

    org.mockito.MockedStatic.verify(VerificationMode, Verification)

Is there a reason, the VerificationMode from MockitoStatic is at first position?

Issue comments:
No, this might be a simple oversight. @raphw I think we can reverse the order? We would need to add an overload and then deprecate the existing one, which we can delete in Mockito 4.0.0.
No, I don't think I had an intention with the order, possibly to have the lambda last what often works better with languages like Kotlin. But I think consistency is the better goal. 
@bohni Do you mind sending us a PR with the added method + deprecation?
OK, I will take a look

Pull request review comments:

Patch that resolved the issue:
diff --git a/src/main/java/org/mockito/MockedStatic.java b/src/main/java/org/mockito/MockedStatic.java
index ac291ba33c..b1089cdbf0 100644
--- a/src/main/java/org/mockito/MockedStatic.java
+++ b/src/main/java/org/mockito/MockedStatic.java
@@ -35,14 +35,21 @@ public interface MockedStatic<T> extends ScopedMock {
      * See {@link Mockito#verify(Object)}.
      */
     default void verify(Verification verification) {
-        verify(times(1), verification);
+        verify(verification, times(1));
     }
 
     /**
      * See {@link Mockito#verify(Object, VerificationMode)}.
+     *
+     * @deprecated Please use {@link MockedStatic#verify(Verification, VerificationMode) instead
      */
     void verify(VerificationMode mode, Verification verification);
 
+    /**
+     * See {@link Mockito#verify(Object, VerificationMode)}.
+     */
+    void verify(Verification verification, VerificationMode mode);
+
     /**
      * See {@link Mockito#reset(Object[])}.
      */
diff --git a/src/main/java/org/mockito/internal/MockedStaticImpl.java b/src/main/java/org/mockito/internal/MockedStaticImpl.java
index 7c3af584eb..0c9456e030 100644
--- a/src/main/java/org/mockito/internal/MockedStaticImpl.java
+++ b/src/main/java/org/mockito/internal/MockedStaticImpl.java
@@ -61,6 +61,11 @@ public <S> OngoingStubbing<S> when(Verification verification) {
 
     @Override
     public void verify(VerificationMode mode, Verification verification) {
+        verify(verification, mode);
+    }
+
+    @Override
+    public void verify(Verification verification, VerificationMode mode) {
         assertNotClosed();
 
         MockingDetails mockingDetails = Mockito.mockingDetails(control.getType());


Test patch:
Repository: mockito/mockito
Issue: Please do a release, as we want to use mockito on jdk 17.

Hi.
I'm tracking why commons-io will fail ci on JDK17.
After tracking I finally found out the latest mockito relase use ASM 9.0 which cannot handle jdk 17.
As you are using 9.1 now, who can handle JDK17,  I hope we can get it a release...
Thanks!
https://github.com/xenoamess-fork/commons-io/runs/1945142044

check that

 - [ ] The mockito message in the stacktrace have useful information, but it didn't help
 - [ ] The problematic code (if that's possible) is copied here;
       Note that some configuration are impossible to mock via Mockito
 - [ ] Provide versions (mockito / jdk / os / any other relevant information)
 - [ ] Provide a [Short, Self Contained, Correct (Compilable), Example](http://sscce.org) of the issue
       (same as any question on stackoverflow.com)
 - [ ] Read the [contributing guide](https://github.com/mockito/mockito/blob/release/3.x/.github/CONTRIBUTING.md)




Issue comments:
Sadly we can't guarantee yet that Mockito fully works on JDK 17, given that Gradle doesn't support JDK 16+ (https://github.com/mockito/mockito/pull/2211#issuecomment-782884920) That said, I can publish a new release to Maven Central this week, which seems appropriate regardless of JDK 17 support.

Pull request review comments:

Patch that resolved the issue:
diff --git a/version.properties b/version.properties
index 84772019f6..032fc68655 100644
--- a/version.properties
+++ b/version.properties
@@ -1,2 +1,2 @@
 # Used by Shipkit Auto Version Gradle plugin: https://github.com/shipkit/shipkit-auto-version
-version=3.7.*
+version=3.8.*


Test patch:
Repository: mockito/mockito
Issue: Example in javadoc of ArgumentMatcher has missing parenthesis

check that

 - [x] The problematic code (if that's possible) is copied here;
       Note that some configuration are impossible to mock via Mockito
 - [x] Read the [contributing guide](https://github.com/mockito/mockito/blob/release/3.x/.github/CONTRIBUTING.md)



The javadoc for ArgumentMatcher contains some example code which misses a pair of parenthesis in one case at https://github.com/mockito/mockito/blob/c86fe047d557bd2ec364d59a99430792f3920e96/src/main/java/org/mockito/ArgumentMatcher.java#L64

Issue comments:

Pull request review comments:

Patch that resolved the issue:
diff --git a/src/main/java/org/mockito/ArgumentMatcher.java b/src/main/java/org/mockito/ArgumentMatcher.java
index a1e27c98d6..f51d7e5f79 100644
--- a/src/main/java/org/mockito/ArgumentMatcher.java
+++ b/src/main/java/org/mockito/ArgumentMatcher.java
@@ -61,7 +61,7 @@
  *
  * List mock = mock(List.class);
  *
- * when(mock.addAll(argThat(new ListOfTwoElements))).thenReturn(true);
+ * when(mock.addAll(argThat(new ListOfTwoElements()))).thenReturn(true);
  *
  * mock.addAll(Arrays.asList(&quot;one&quot;, &quot;two&quot;));
  *


Test patch:
Repository: mockito/mockito
Issue: how to solve gradle sync failed after 'Add basic Android instrumented and unit tests'

Hello

I got gradle sync fail with 'Add basic Android instrumented and unit tests'(#2360).

> This version of the Android Support plugin for IntelliJ IDEA (or Android Studio) cannot open this project, please retry with version 4.2 or newer.

I think that it is caused with below.

build.gradle
> classpath 'com.android.tools.build:gradle:4.2.1' 

the downgrading of gradle version is needed but I'm not sure it is proper...
> classpath 'com.android.tools.build:gradle:4.1.2'

Regards

Issue comments:
Yes, I ran into the same issue. Fix is up at #2380 Apologies for the breakage!

Pull request review comments:

Patch that resolved the issue:
diff --git a/build.gradle b/build.gradle
index 0587470df7..eb7bed5197 100644
--- a/build.gradle
+++ b/build.gradle
@@ -14,7 +14,7 @@ buildscript {
         classpath 'org.shipkit:shipkit-auto-version:1.1.19'
 
         classpath 'com.google.googlejavaformat:google-java-format:1.10.0'
-        classpath 'com.android.tools.build:gradle:4.2.1'
+        classpath 'com.android.tools.build:gradle:4.0.2'
         classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:1.5.21"
     }
 }


Test patch:
Repository: mockito/mockito
Issue: Update javadoc of `Strictness.STRICT_STUBS`

https://github.com/mockito/mockito/blob/c4cce85decc1639db41209696131d41e6d722d2f/src/main/java/org/mockito/quality/Strictness.java#L68

https://github.com/mockito/mockito/blob/c4cce85decc1639db41209696131d41e6d722d2f/src/main/java/org/mockito/MockSettings.java#L371

It looks like despite of the plan, `LENIENT` is still the default in version 4.

Issue comments:
I would be happy to review a PR that removes the sentence altogether
I am ready to prepare PR, but I don't have permissions to push 

Pull request review comments:

Patch that resolved the issue:
diff --git a/src/main/java/org/mockito/quality/Strictness.java b/src/main/java/org/mockito/quality/Strictness.java
index b25cab33e6..76cd552b38 100644
--- a/src/main/java/org/mockito/quality/Strictness.java
+++ b/src/main/java/org/mockito/quality/Strictness.java
@@ -65,7 +65,6 @@ public enum Strictness {
      * Ensures clean tests, reduces test code duplication, improves debuggability.
      * Offers best combination of flexibility and productivity.
      * Highly recommended.
-     * Planned as default for Mockito v4.
      * Enable it via our JUnit support ({@link MockitoJUnit}) or {@link MockitoSession}.
      * <p>
      * Adds following behavior:


Test patch: