jmockit with gradle under android studio
<p>My Android Studio project has never done command line compiles.  All compiles have been done using the IDE.  I am trying to introduce scripted compiles on a continuous integration server, and I have run into a snag:
my build.gradle is as follows:</p>

<pre><code>apply plugin: 'com.android.application'

android {
    compileSdkVersion 19
    buildToolsVersion "22.0.1"

    defaultConfig {
        applicationId "com.foo.myapplication"
        minSdkVersion 18
        targetSdkVersion 19
    }

    buildTypes {
        release {
           minifyEnabled false
           proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt'
        }
    }
    repositories {
        maven { url 'http://repo1.maven.org/maven2' }
    }
}
dependencies {
    compile project(':library')
    compile project(':gdHandheld')
    testCompile 'org.jmockit:jmockit:1.28'
    testCompile 'junit:junit:4.12'
    compile fileTree(dir: 'libs', include: ['*.jar'])
 }
</code></pre>

<p>My tests runs fine when I run through android studio.I am using jmockit as a testing framework like this:</p>

<pre><code>@Test
public void onOptionsItemSelectedRequestHelpTest(@Mocked final MenuItem menuItem,
                                                 @Mocked final RequestHelpDialogFragment requestHelpDialogFragment)
{
    Assert.assertTrue(true);
}
</code></pre>

<p>When I run <code>gradlew check</code> from the commandline, however, (with gradle-2.14.1-all) then I believe the classpath is incorrect somehow.  it throws the error</p>

<pre><code>java.lang.Exception: Method onOptionsItemSelectedRequestHelpTest should have no parameters
</code></pre>

<p>I am reasonably sure that the problem is one of ordering.  jmockit must appear BEFORE junit on the classpath when running the unit tests.  <code>gradlew --debug</code> pretty much confirms that the order is reversed.  What do I need to do here to get jmockit to properly allow junit to have arguments to the tests?  BTW, I do also want to be able to have code coverage in this, once I get the tests passing (possibly with jacoco).  I mention that just because I don't want to have a solution that would break jacoco compatibility</p>