breaks declaring @BindingAdapter in a library project with the new android databinding library

Issue #45 resolved
Evan Tatarka
created an issue

This is related to #38, but unfortunatly, version 1.5 didn't fix it. If you have a library project that declares an @BindingAdapter than an application that depends on that library should be able to use it. However, when you apply the android-apt plugin, it fails to find it. I have an example project that reproduces this issue on github.

Comments (7)

  1. Hugo Visser repo owner

    Well, #38 is fixed, since the build would break without applying the binding plugin manually and now it's applied automatically. This seems to be something different, I suspect related to #37. Adding a project reference causes changes in the build order and that might be causing the issue for some reason. Spoke too soon, have to inspect the debug builds outputs for differences, not quite sure what is going on.

  2. Hugo Visser repo owner

    OK, confirmed that is caused by creating a dependency on the lib project. I also see a mix of release and debug sources that get pulled in from the lib in that case, whilst it's only using release without android-apt. Looks like the build order is out smarting the build tools.

  3. Hugo Visser repo owner

    Remove build reordering for project dependencies. This can cause side effects, breaking builds. For custom annotation processors contained in a project dependency the 'processor' option for executing a processor by class can be used now. Fixes #37, #45

    → <<cset 7de92592a9a3>>

  4. Hugo Visser repo owner

    Base the processor path on the apt configuration + the configured classpath for javac in order to make sure the compile classpath is included in the processor path at all times. Should be equivalent to compile + provided scopes which is what we want. Fixes #45

    → <<cset 41cffa8c8540>>

  5. Log in to comment