Error resolving Gradle reference

zmattr · September 11, 2020, 6:15pm

I am encountering a fatal build error trying to resolve a reference for recent versions of Google’s ConstraintLayout library for Android. The most recent stable versions are 2.0.1, 2.0.0, and 1.1.3. I am able to build using 1.1.3 but not for 2.0.+. (But I have to use 2.0.+, since when I reference 1.1.3 in my main project, I get a “missing method” runtime error on a method that is apparently referenced by a different library I include).

Here is a sample project. It’s a clean new project with only a reference to the ConstraintLayout library added. As it stands, it generates 4 build errors “attibute ___ has already been defined”. Seems like possibly a merging issue? Reverting the gradle reference to 1.1.3 causes the errors to go away.
org.gradlerefs.test.zip (29.3 KB)

mh · September 11, 2020, 7:35pm

FWIW< the reference resolves fine for me?

Doesn’t look like it, as this happens on AAPT, long before we merge the manifest. this is the offending XM<:

    <declare-styleable name="PropertySet"><attr name="android:visibility"/><attr name="visibilityMode"/><attr format="float" name="android:alpha"/><attr name="motionProgress"/><attr name="layout_constraintTag"/></declare-styleable> //  aapt: Attribute "android:alpha" has already been defined
...
    <declare-styleable name="Transform"><attr name="android:elevation"/><attr name="android:rotation"/><attr name="android:rotationX"/><attr name="android:rotationY"/><attr name="android:scaleX"/><attr name="android:scaleY"/><attr name="android:transformPivotX"/><attr name="android:transformPivotY"/><attr format="dimension" name="android:translationX"/><attr format="dimension" name="android:translationY"/><attr format="dimension" name="android:translationZ"/></declare-styleable> //  aapt: Attribute "android:translationX" has already been defined
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    //  aapt: Attribute "android:translationY" has already been defined
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    //  aapt: Attribute "android:translationZ" has already been defined

from /Debug/Cooper-Android/aar/constraintlayout-2.0.0/res/values/values.xml

I’m guessing constraintlayout-2.0.0 is not compatible with androidx, as this seems reminiscent of many errors I have seen when mixing legacy APIs with androidx. But thats just a guess.

zmattr · September 11, 2020, 7:44pm

Ah sorry for the confusion - the references resolve fine for me, the error is with building the project.

And the ConstraintLayout I’m using is actually an AndroidX library, and so are the other references (although this is the only reference in my sample project).

zmattr · September 11, 2020, 8:38pm

I think I did determine the cause of the “method not found” error that prevents me from reverting to 1.1.3. When I revert to 1.1.3, constraintlayout requests constraintlayout-solver 1.1.3 but it resolves to 2.0.1. The method not found exception is

java.lang.NoSuchMethodError: No virtual method setWrapWidth(I)V in class Landroidx/constraintlayout/solver/widgets/ConstraintWidget; or its super classes (declaration of 'androidx.constraintlayout.solver.widgets.ConstraintWidget' appears in /data/app/~~6ZjXfVg7V1iyQtNqAdM0kg==/com.accordancebible.accordance-D1YSy9bMkXDJaIrM5lbUxg==/base.apk!classes18.dex)

It looks like constraintlayout 1.1.3 still pulls in constraintlayout-solver 2.0.1 internally, and constraintlayout-solver 2.0.1 is attempting to reference a method from constraintlayout 2.0.1 that did not exist in 1.1.3.

I suppose if I use the brackets to hard-limit which version a reference pulls, I would also want its references hard-limited as well, right? In this case I would at least need the option to do so.

zmattr · September 14, 2020, 1:23pm

[ removed comment - see below ]

zmattr · September 14, 2020, 1:40pm

Ah wait, there is a constraintlayout-solver package in my Ebuild/Packges/Gradle folder, just not in my intermediates folder. I have versions 1.1.3 and 2.0.1 in my local gradle folder, but it looks like neither is being pulled into the build although the build seems to expect it…

zmattr · September 14, 2020, 1:42pm

It looks like the ultimate cause of the issue is that the jar for constraintlayout-solver version 2.0.1 is pulled in instead of version 1.1.3, when I requested constraintlayout 1.1.3.

zmattr · September 14, 2020, 1:56pm

Confirmed this is the issue. I at least have my build working for now, by copying my constaintlayout-solver:1.1.3 gradle cache folder to 2.0.1 so the correct one is pulled in.

zmattr · October 14, 2020, 2:49pm

Just wanted to bring attention back to this since it seems like it was dropped. This is still a significant issue for me. To get it to work, I have to copy an old dependency into my gradle cache and rename it to make EBuild think it’s the latest dependency. Every time the dependency is updated remotely, I get a runtime crash and have to do it again.

zmattr · October 14, 2020, 2:54pm

I looked back at it and think I’ve figured out what needs to be changed. To use the example that I’m facing, androidx.constraintlayout:constraintlayout:1.1.3 has a dependency on androidx.constraintlayout:constraintlayout-solver:1.1.3. But even when I fix the version to [1.1.3] in my project file, constraintlayout-solver resolves to the latest (currently 2.0.2).

My suggestion is that if a dependency’s version is fixed with [version] then all of its internal dependencies should also be fixed to the version specified in the pom file.

The pom file for constraintlayout:1.1.3 lists its dependency on

<dependency>
  <groupId>androidx.constraintlayout</groupId>
  <artifactId>constraintlayout-solver</artifactId>
  <version>1.1.3</version>
  <scope>compile</scope>
</dependency>

But it looks like the version for the pom file dependency is being treated as “equal or greater than” rather than “exactly”.

mh · October 14, 2020, 4:41pm

I believe that is/was the case, but I’ll have a look and fix. Since this thread as gotten long, do you have a latest simple test case that lets me easily reproduce this and test the fix? If so, I’ll have a go at it this afternoon.

thanx,
marc

zmattr · October 14, 2020, 4:49pm

Sure, here’s the test project:

org.gradlerefs.test.zip (29.6 KB)

constraint-layout-versionsPNG

mh · October 14, 2020, 5:17pm

hmm:

b713042ae (marc hoffman 2018-02-12 09:11:12 -0400 162)         var lSuffix: String := if lVersion.EndsWith("]") or lVersion.EndsWith(")") then lVersion[length(lVersion)-1] else "";
b713042ae (marc hoffman 2018-02-12 09:11:12 -0400 163) 
85f51fe3c (marc hoffman 2018-07-14 16:22:05 -0400 164)         //if (length(lSuffix) > 0) and not ((lVersion2 = '*') or lVersion2.EndsWith("]") or lVersion2.EndsWith(")")) then
85f51fe3c (marc hoffman 2018-07-14 16:22:05 -0400 165)           //lVersion2 := lVersion2+lSuffix;
b713042ae (marc hoffman 2018-02-12 09:11:12 -0400 166) 
c897e0085 (marc hoffman 2019-01-21 11:23:04 -0400 167)         var lExisting := Project.Objects["GradleReference"].Where(r -> r.Name.ToLowerInvariant().StartsWith(lName2Lower+":")).FirstOrDefault;
567030730 (marc hoffman 2017-02-06 17:44:11 -0400 168)         if assigned(lExisting) then begin

this was disabled July 2018:

85f51fe3c: Fix for Gradle dependency checking being a bit too strict

I wonder why, and what else will regress if I change it back now…?

zmattr · October 14, 2020, 5:44pm

Assuming lVersion2 is an internal dependency of a requested dependency, I don’t see what could break that shouldn’t break… If a maven library specifies a specific version for a dependency in its pom file, I can’t think of a case where you should choose to use a different version than the one requested.

mh · October 14, 2020, 6:56pm

Right. basically that adds ], if the parent reference had ]. But since ei had this in thjer before, and remove dit, im sure it was for a reason…

I’ve added it back for now, we’ll see…

mh · October 15, 2020, 11:25am

I’ve uploaded a new build for you.

Note that if you’re on Mac and using the new external compiler with Fire, it wont affect the resolving you see in the IDE’s tree view (i.e. the numbers shown in your screenshot); only what happens when you do the actual build.

zmattr · November 17, 2020, 5:08pm

Found it

E: Cannot adjust existing dependency com.google.android.gms:play-services-basement from version 17.4.0] to 17.0.0].

com.resolverefs.zip (29.4 KB)

mh · November 17, 2020, 5:19pm

suggestions?

zmattr · November 18, 2020, 4:52pm

I’m really not sure. I’ll have to look into how Gradle handles this I guess.

zmattr · November 18, 2020, 4:58pm

ConstraintLayout:1.1.3 requests ConstraintLayout-Solver:1.1.3. Allowing solver to bump to a newer version (for example, 2.0.2) causes a crash due to a resource mismatch. So in this case ConstraintLayout-Solver must be locked at 1.1.3.

AppCompat:1.2.0 requests Annotation:1.1.0 and also DrawerLayout:1.0.0. DrawerLayout:1.0.0 requests Annotation:1.0.0. So should you force Annotation to 1.1.0 or use 1.0.0?