Annotation processor does not work with Android Gradle build about parceler HOT 16 CLOSED

@hvisser Can you share your build.gradle file?

from parceler.

Sure, though it's not a build issue :) Here's a minimal example that demonstrates the problem without any build file customization. Just create a project and add a class containing @Parcelable and build it from the command line.

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:0.6.+'
    }
}
apply plugin: 'android'

repositories {
    mavenCentral()
}

android {
    compileSdkVersion 19
    buildToolsVersion "19.0.0"

    defaultConfig {
        minSdkVersion 7
        targetSdkVersion 19
    }

    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_7
        targetCompatibility JavaVersion.VERSION_1_7
    }
}

dependencies {
    compile 'org.parceler:parceler:0.2.1'
    compile 'org.parceler:parceler-api:0.2.1'
}

from parceler.

The issue is that the annotation processor code imports the Android SDK classes. These classes are not available to the processor in a Gradle build. At compilation time the processor is therefore throwing ClassNotFoundExceptions when it is invoked. In other words, the annotation processor itself has a dependency on the Android runtime which is causing the problem. Maven builds most likely put the Android SDK on the compile classpath, while Gradle builds put the SDK on the bootclasspath.

from parceler.

I need to look at this issue in more depth, but my initial thought is you will need to include the Android library on the classpath during compile time. Parceler will generate classes which, for one, extend the android.os.Parcelable class. Therefore, these generated classes will need to be compiled against the Android library. I've had success with a Gradle build with Parceler over on the Transfuse project here:

https://github.com/johncarl81/transfuse/tree/master/examples/gradle

Would this work for your example?:

dependencies {
    compile 'org.parceler:parceler:0.2.1'
    compile 'org.parceler:parceler-api:0.2.1'
    compile 'com.google.android:android:2.1_r1'
}

The other option is to find a way to remove Android as a dependency of Parceler using the String-for-Class referencing replacement that they did over on the Butterknife project.

Thoughts?

from parceler.

No, sorry, that would not be a very great fix or workaround. The Gradle plugin does set up a proper Android build environment already and I don't want to add the android sdk as a compile time dependency; that's what the plugin does already. Besides, there are no official Android SDK published in Maven Central and including those dependencies can lead to other side effects.
It's not an issue that the generated code depends on Android, you can get those classes using the type mirror, that will work correctly. That's what butterknife is doing as well: Jake removed the literal references to OnClickListener.class and replaced that with android.view.OnClickListener, but this is used to get to an Element from the mirror api.
In the case of parceler it might be hard maybe, the code depends on android .class references and not on references from the mirror api, but I haven't looked enough at the code to really get what it would take to adjust it to remove the Android dependency in the processor itself. I hope I can go to the code a bit more tomorrow and maybe propose a fix.

from parceler.

@hvisser I was able to eliminate the android dependency with this strategy... will push out a new version tonight or early tomorrow.

Thanks for highlighting this.

from parceler.

Awesome, looking forward to it! Thanks!

from parceler.

@hvisser Removing the Android dependency was successful: fe13ea4

I've issued a new release of Parceler under version 0.2.2 to maven central. Let me know how this works for you.

from parceler.

Almost! The generated code has a dependency on import org.androidtransfuse.util.Generated which is not in parcelable-api, so I'm still getting compile errors. Including parcelable as compile time dependency pulls in a whole bunch of stuff that shouldn't be included I guess.

I'm using my android-apt plugin to set up the build, this is my build.gradle as a reference. The apt config makes sure javac knows about the compiler, but does not put it on the project compile path, unlike mavens' provided scope, which just omits the dependency from packaging.

Including the @Generated in the api jar would work or I could pull in transfuse-api for only that annotation, but that brings a lot of extra classes and a few dependencies along.

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'com.neenbedankt.gradle.plugins:android-apt:1.1'
        classpath 'com.android.tools.build:gradle:0.6.+'
    }
}
apply plugin: 'android'
apply plugin: 'android-apt'

repositories {
    mavenCentral()
}

android {
    compileSdkVersion 19
    buildToolsVersion "19.0.0"

    defaultConfig {
        minSdkVersion 7
        targetSdkVersion 19
    }

    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_7
        targetCompatibility JavaVersion.VERSION_1_7
    }
}

dependencies {
    apt 'org.parceler:parceler:0.2.2'
    compile 'org.parceler:parceler-api:0.2.2'
}

from parceler.

There is a couple other Transfuse classes that Parceler depends on, side effects of originally being an integral part of Transfuse and using parts of Transfuse as its own DI engine.

I've built and deployed a snapshot that solves these dependency issues under 0.2.3-SNAPSHOT, can you give that a try?

I am also not a Gradle expert by any means, would you care to supply a simple Android Gradle project for the example portion of Parceler? This would fulfill #6 .

from parceler.

Yep, with 0.2.3-SNAPSHOT all looks great, in the sense that it compiles and the generated code is OK now, I haven't tested actual using it, but I assume that would work just fine. As for #6, the Gradle file I posted in my last comment is the bare minimum for an Android project with parceler as a dependency.

I'm looking at the example and I don't really get how you'd run that using Maven? For it to run in a Gradle project it should probably be a project with tests only or an app project of some kind. I'd be happy to send you a pull request for that in any case.

from parceler.

Good to hear. I will review further and issue a non-snapshot. A PR with a simple Android project would be much appreciated.

The current example project doesn't actually serialize using an Android Parcelable, but it demonstrates the basic usage of the Paceler api (Parcels and ParcelWrapper). As it stands it is just invokable by running the main method in an IDE or on the command line manually. A proper Android project example would be much better.

from parceler.

I just released Parceler under 0.2.3 with a couple of other tweaks. Works well under Gradle for me, let me know how it works for you @hvisser .

from parceler.

Yes, this works fine now with Gradle. I am trying to think of an example, but I was running into a slight issue: when you have a pojo with a field that is a list of things that are annotated with @Parcelable, wrapping that will fail, since the individual elements are not wrapped. I guess the ParcelWrapper that is generated should wrap the list in this case...anyway, I'll think of a different example or just make it even more simple and then I'll let you know.

from parceler.

Great. Ah, that is a missing feature (List or @Parcels) and I think it would be reasonably easy to add (#12).

I also updated Transfuse so it works with Gradle properly using the same techniques discussed (32b60724a11bb2cf894545288d651981096aae04). I have an example Gradle Android project here: https://github.com/johncarl81/transfuse/tree/master/examples/gradle which doesn't include Parceler, but it may be a good staring point. Either way feedback on that would also be appreciated.

from parceler.

Incorporated into the 0.2.5 release

from parceler.