Resource merging and order of declared dependencies

[James Wald]

I have a multi-project build that is structured like this:

root/

    app/

        build.gradle -> dependencies: libA, libB

    libA/

        src/main/res

            styles.xml -> @style/AppTheme

        build.gradle

    libB/

        src/main/res

            styles.xml -> @style/AppTheme

        build.gradle

When declaring app's dependencies, these produce different resources after the merge process:

dependencies {

    compile project(':libA')

    compile project(':libB')

}

dependencies {

    compile project(':libB')

    compile project(':libA')

}

The library that is declared first in the dependencies block wins and the other library's @style/AppTheme resource is ignored. Since the libraries both declare @style/AppTheme and do not depend on each other, I was expecting the build to fail with a resource merging conflict. I'm wondering whether this is a bug or working as intended?

[Xavier Ducrohet]

This is working as intended (it worked like this in Ant/ADT as well).

We need to add diagnostic tools to let you devs understand exactly what's going on.

--
You received this message because you are subscribed to the Google Groups "adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Xavier Ducrohet
Android SDK Tech Lead
Google Inc.
http://developer.android.com | http://tools.android.com

Please do not send me questions directly. Thanks!

[James Wald]

Huh okay, good to know. I never realized the order of project dependencies had this effect back in the Ant days either. Thanks again!

[Michael Wallstedt]

To follow up on this idea, what is the expected behavior with a config like the following?

app depends on: A, B

B depends on: A

The gradle doc states "The priority of the merge order from lowest to highest is libraries/dependencies -> main src -> productFlavor -> buildType." From the perspective of module B, its resources should take precedence over those in A (since A is a dependency). However, from the perspective of the app module, A appears before B, so A should take precedence.

In practice, we have some evidence that the behavior is not easy to predict. Some seemingly unrelated change in B caused it take priority, when A had priority prior to the change.

[Michael Wallstedt]

I think we've accounted for the actual difference. A change in lib B meant that the resources were not found, so gradle fell back to A. Under normal circumstances, B will take precedence.

[James Wald]

That sounds right. Parent projects have precedence over child projects no matter how dependencies are declared. The order of dependency declarations only affects sibling projects that don't depend on each other. This can get even more complicated when sibling projects have dependencies that overlay each other's resources.

It would be very helpful if additional tooling was developed in this area so we could better understand what is happening. A good start might be improvements with code navigation. I often find that the "jump to declaration" action takes me to generated R classes rather than resource files. When that action does work as expected, it presents a list of relevant resource files but the popup shows the same project name for all of the options rather than the actual project that each resource file belongs to. I'll try to find a bit of time to file separate issues for these concerns.

You received this message because you are subscribed to a topic in the Google Groups "adt-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/adt-dev/aWxyzwVaDmM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to adt-dev+u...@googlegroups.com.