TurboManage

David Chandler's Journal of Java Web and Mobile Development

  • David M. Chandler


    Web app developer since 1994 and former Developer Advocate with Google now residing in Colorado. Besides tech, I enjoy landscape photography and share my work at ColoradoPhoto.gallery.

  • Subscribe

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 242 other followers

  • Sleepless Nights…

    March 2017
    S M T W T F S
    « May    
     1234
    567891011
    12131415161718
    19202122232425
    262728293031  
  • Blog Stats

    • 848,524 hits

Archive for the ‘IntelliJ’ Category

Debug an Android annotation processor with gradle and IntelliJ (or Eclipse)

Posted by David Chandler on June 9, 2014

Alex Gherschon and I have recently added maven support to storm-gen (note: I plan to push to Maven Central this week). You can now build and install storm-gen to your local maven repository with

git clone https://github.com/turbomanage/storm-gen.git
cd storm-gen/storm-apt
mvn clean install

Since gradle can pull in maven artifacts, you can then include storm-gen in your gradle build file like this:

apply plugin: 'android'
apply plugin: 'android-apt'


android {
    compileSdkVersion 19
    buildToolsVersion "19.0.3"

    defaultConfig {
        minSdkVersion 10
        targetSdkVersion 19
        versionCode 1
        versionName "1.0"
    }
    buildTypes {
        release {
            runProguard false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt'
        }
    }
}

dependencies {
    compile 'com.android.support:appcompat-v7:+'
    compile 'log4j:log4j:1.2.17'
    compile 'javax.persistence:persistence-api:1.0'
    compile 'com.turbomanage.storm:storm-api:0.98'
    apt 'com.turbomanage.storm:storm-impl:0.98'
}

Now here’s the fun part. Previously, in order to debug and set breakpoints in the annotation processor itself, I used Eclipse RCP and ran it as an Eclipse plugin. Fortunately, there’s now an easier way using Java remote debugging. There are several variations on this technique (configuring an annotation processor directly in IntelliJ or debugging a gradle script). Unfortunately, Android Studio rejected my adding the Xdebug JVM args directly to the gradle script. However, I found this workaround. It is not fully integrated with AS, but does allow me to debug the annotation processor on demand by running the gradle script.

Add these lines to your ~/.gradle/gradle.properties:

org.gradle.daemon=true
org.gradle.jvmargs=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005

Then do something that causes the gradle daemon to start.

gradle --daemon

Now you can go into IntelliJ or Android Studio and attach a remote debugger. I use IntelliJ because AS won’t import the storm-gen maven projects and the whole point of this exercise is to set breakpoints in the storm-gen annotation processor. The screenshot shows configuring a remote debugger in IntelliJ. Just accept the defaults and make sure the port number matches your gradle.properties. It should also work in Eclipse.

remote debug config

Configure a remote debugger in IntelliJ

The remote debugger should attach to the running gradle daemon. You can then tickle the annotation processor by running a build. For example, this runs the storm-gen tests on an already-running emulator or connected device:

cd storm-test
gradle clean connectedCheck

When the annotation processor runs, your breakpoint in IntelliJ (or Eclipse) should fire.

One caution with this technique is that Android Studio will also use the gradle daemon because it’s now configured in your gradle.properties. But if you launched the daemon from the command line, AS will try to launch it again and you’ll see an error message about the port already in use. In that case, simply kill the running gradle process and AS should be happy.

Posted in Android, IntelliJ | 1 Comment »

 
%d bloggers like this: