Potential ProGuard and/or attribute issues with 3.7.0

[friederbluemle]

Several users have reported issues with version 3.7.0, e.g. #350 #351 #353 #354
Initial evaluation suggests the changes are related to updated build dependencies, merged in #306

Let's keep this issue to discuss further findings to get to the bottom of this.

[davemorrissey]

Proguard config added in 3.7.0 is another candidate. So far I have not reproduced this, I have made a signed release of the sample project using version 3.7.0 from the maven repository and it worked without issues.

[friederbluemle]

Yeah, same here. The sample project runs fine using 3.7.0 in a release configuration with ProGuard enabled (default config).

[friederbluemle]

Oooh! I just noticed checking mvnrepository that 3.6.0 and previous versions were deployed as an aar file, but 3.7.0 is just a regular jar! So the issues might be related to that. A jar can only class files whereas the aar also can contain resources (e.g. the necessary ProGuard rules).
That still doesn't explain why the sample project works fine, but just putting this here..

[friederbluemle]

Also, 3.7.1 does not appear to be on mvnrepository yet. Did you deploy to bintray?

[friederbluemle]

Okay, so it definitely has to do with the deployment. I just did a side-by-side comparison of 3.6.0 (aar) and 3.7.0 (zip). What's pretty obvious is that values.xml (which includes the necessary attrs.xml), as well as AndroidManifest.xml are missing in 3.7.0:

[davemorrissey]

Yes, the new release.gradle file uploads the jar file plus javadocs. I've tried just reverting the content of the release config back to what it was but that doesn't work. It's next to impossible to find a decent reference for this.

I don't know why 3.7.1 isn't in the repository, I released it as normal.

[davemorrissey]

I don't use BinTray, I use the Sonatype central repository manager. All the tutorials I can find seem to use BinTray and rely on including config gradle files from random github accounts - I can't say I'm too keen on that.

I'm not having any luck getting the new setup to upload an aar file, even though the packaging is specified as aar.

[davemorrissey]

3.7.1 is on maven central but not indexed by their UI yet. The aar is here: http://central.maven.org/maven2/com/davemorrissey/labs/subsampling-scale-image-view/3.7.1/subsampling-scale-image-view-3.7.1.aar

[friederbluemle]

OK more findings, after checking the library on jcenter.bintray.com
(which contains all three versions of interest: 3.6.0, 3.7.0, and 3.7.1):

Something interesting:

• 3.6.0 was deployed as .aar only (including signatures)
• 3.7.0 was deployed as javadoc, sources, aar, and jar
• 3.7.1 was deployed as .aar only (no signatures)

Of course the signatures won't make a difference. Interesting about 3.7.0 is that the .aar file was modified 3 days ago, whereas the rest of the files were modified 6 days ago. Did you somehow add this file later on? Not sure how that would happen... jcenter is mirroring maven central

Most likely what is happening to some users:

Their dependency resolution tool is somehow downloading the .jar file of 3.7.0 instead of the .aar file. These users might have success adding an @aar modifier to their dependency declaration, e.g.

compile 'com.davemorrissey.labs:subsampling-scale-image-view:3.7.0@aar'

https://stackoverflow.com/questions/26250790/what-does-aar-means-in-gradle-compile-task

Obviously, since this library contains resources, it makes no sense to deploy it as jar in the first place. This was probably a mistake in the release.gradle file, and was likely the only thing that had to be reverted. Of course that is pending further investigation. I'll continue to try to reproduce here.

[davemorrissey]

I've just released 3.7.2. It contained just the aar, the pom, and signatures. I just deleted a lot of the additions from release.gradle - first time I tried that I only got signatures but a second attempt worked.

[friederbluemle]

Great, thanks!! 👍

Meanwhile, I was able to reproduce the issue locally.

As suspected, the issue comes down to the missing resources in the jar file.
BUT: Running the sample app with just the jar library works without issues. The reason is that non of the xml layout files in the sample app use any of the custom attributes defined in attrs.xml of the library project!

After adding a app:zoomEnabled="false" to one of the SubsamplingScaleImageView xml elements, the build failed right away. The app namespace is declared like this:

xmlns:app="http://schemas.android.com/apk/res-auto"

Also, as speculated, adding a @aar to the 2.7.0 dependency will fix the issue an correctly pull the aar file with resources. Not that it really matters - people should update to 2.7.2 asap.
Thanks again for this project, and sorry for not paying closer attention to the release.gradle script in the original PR!

[davemorrissey]

Thanks for your help with this, I should have spotted the build contained more artifacts than usual, all I did was check the aar was there. The packaging is specified as aar in the pom so it seems like that should be the default even when a jar is present.

The devs who reported this didn't seem to be using any of the custom attributes in their layouts, which is why I didn't try that myself!