After using Android Studio 3, Java application dependencies can no longer be resolved, so what to do about it

Symptoms

After changing to com.android.tools.build: gradle: 3.0.1 to support Android Studio 3.x, the dependency of the pure Java application that could be executed from Application of Run Configuration could not be resolved. That is, NoClassDefFoundError is displayed.

In short, there was such a Java Application in a Module.

Action (Best practice [here](https://qiita.com/KoheiKanagu/items/0836d11c608d9394a36e# and best practice))

** Note: This won't stop at the breakpoint. How you can stop will be described later **

In this way, set it so that it can be executed with gradle run. In the image, the module name is lib. :yourModuleName:run

And add the following to build.gradle of the target module.

build.gradle

apply plugin: 'application'

mainClassName = "your.main.class.myClass"

In short, is it similar to the problem that resource could not be obtained? Until Android Studio generates an executable Jar containing resources from a Java Library module

Execution method that stops even at a breakpoint

** Note: It's no good because the gradle task will die after a while after the break ... **

Suppose you have a Java module called lib, you have myClass.java, and you are referencing Gson.

myClass.java

package com.example.lib;

import com.google.gson.GsonBuilder;

public class myClass {
    public myClass() {
        System.out.println(GsonBuilder.class);
        System.out.println("hoge");
    }
    public static void main(String[] args) throws Exception {
        new myClass();
    }
}

Add a JavaExec task to build.gradle with an appropriate name. If you change the name such as ʻexecute Hote or ʻexecute Piyo and set each main, you can handle modules that want to create multiple mains.

build.gradle

apply plugin: 'application'

dependencies {
    implementation fileTree(include: ['*.jar'], dir: 'libs')
    implementation 'com.google.code.gson:gson:2.8.2'
}

mainClassName = "" //It doesn't seem to make sense, but without it the entire project build won't work

task executeMyClass(type: JavaExec) {
    main = "com.example.lib.myClass"
    classpath = sourceSets.main.runtimeClasspath
}

Add Remote from Add New Configuration. Name is appropriate. Search sources using module's classpath: may remain as <whole project>

Add Run Gradle task from Before launch. Grade project is the project you want to run, this time lib. For Talks, use : lib: executeMyClass --debug-jvm. (--Debug-jvm waits for the debugger to attach.) In summary, it looks like this.

Run

When Run debug is executed, ʻexecuteMyClass is executed according to Before launch`. But this doesn't end because it's waiting for an attachment from the debugger.

So stop. In short, click the one on the far right of the image. Then stop at the breakpoint.

JavaExec Gradle to execute Java class (without modifying build.gradle)

The feeling that it was executed because it was stopped was amazing, and it became more troublesome than in Android Studio 2.x, but ~~ It works for the time being, so it's good. ~~ It doesn't move.

~~ And best practices ~~

As in the previous chapter, create task executeMyClass in build.gradle in the same way. Add Remote from Add New Configuration, but set the Name appropriately and all others are OK by default.

Execute sh as a matter of course.

executeMyClass.sh

./gradlew :lib:executeMyClass --debug-jvm

Then, it stays stopped at EXECUTING.

If you run the Remote you just added in Android Studio with debug ... you can attach it. Congratulations. The error is displayed in the terminal, so you can't click to jump to the dropped class.

I found a way to do it the same as in the Android Studio 2.x era, so the true best practice is ** here **

Digression

It's a lot of work compared to Android Studio 2.x, but is it the only way to avoid being left behind in the times ...? It may be wrong to run Java applications in Android Studio in the first place. (I thought, but if it is a project without an Android module, it is an extra mystery that it can be executed from Application Configuration) I think it's caused by the specification change due to the increase of implementation and api in Gradle plugin 3.x, but I don't really understand the problem ...