NullPointerException by local AAR

[ben-manes]

NullPointerException by local AAR

[dsvoronin]

yep. same here. very frustrating
as "workaround" you can temporarily comment these local dependencies, then run plugin, then uncomment them back.

[olliefreeman]

same here, it seems to be with any local dependencies. As dsvoronin said, workaround of commenting them works though.

[meoyawn]

same here, commenting them

[jochenberger]

I have tried to write a test case for this but I can't get it to work. I have no experience with flat directory repositories. Can anyone provide some test code?

The following works as a quick fix (for me at least). It looked like 'version' was coming out as an empty string rather than null so that's why the currentVersions[key] == version doesn't work. It's probably better to make both of them null or empty strings.

Some more debugging info for @jochenberger if it helps, unfortunately I don't have a test case I can share with you as I'm using a flatDir repo that's provided by someone else and haven't tried to create my own.

Resolved latest dependencies: [:flatDirRepo:;default, ...
Dependency DefaultExternalModuleDependency{group='null', name='flatDirRepo', version='null', configuration='default'} does not use a dynamic version
Comparing current with latest dependencies. current: [null:flatDirRepo:null, ...
latest: [:flatDirRepo:, ...
Checking dependency :flatDirRepo null

diff --git a/src/main/groovy/com/github/benmanes/gradle/versions/updates/DependencyUpdates.groovy b/src/main/groovy/com/github/benmanes/gradle/versions/updates/DependencyUpdates.groovy
index 700c139..7b5b695 100644
--- a/src/main/groovy/com/github/benmanes/gradle/versions/updates/DependencyUpdates.groovy
+++ b/src/main/groovy/com/github/benmanes/gradle/versions/updates/DependencyUpdates.groovy
@@ -170,7 +170,7 @@ class DependencyUpdates {
     Map<Integer, Map<Map<String, String>, String>> versionInfo = latestVersions.groupBy {
         Map<String, String> key, version ->
       project.logger.info('Checking dependency {}:{}', key.group, key.name)
-      if (currentVersions[key] == version) {
+      if (currentVersions[key] == version || currentVersions[key] == null) {
         0
       } else {
         (Math.signum(comparator.compare(version, currentVersions[key]))) as int

[jochenberger]

I'd be grateful if someone could provide a test case that leads to the NPE.

[scompt]

Here's a pretty simplified test case extracted from an app I'm working on. There are two sections in the build.gradle file. The first one, using version 0.5-beta-1 doesn't throw the exception. The second one, using version 0.7 does.

https://www.dropbox.com/s/vr8xrzr739ng3ab/npe_example.tar.gz?dl=0

[jochenberger]

Right, somehow the dependency ends up with different keys in the map with the current versions that in the map with latest versions:

$ ANDROID_HOME=/tmp gradle -i dU --stacktrace
...
Comparing current with latest dependencies. current: [null:viewpagerindicator-2.4.1:null, com.android.tools.build:gradle:1.0.1], latest: [:viewpagerindicator-2.4.1:, com.android.tools.build:gradle:1.0.1]
Checking dependency :viewpagerindicator-2.4.1

Then, the lookup fails. I guess the fix is easy, I'd still prefer a real test case though, as in Spock test case.

[jochenberger]

I can think of multiple way to fix this. Either ignore file-based repositories altogether, report modules with null versions unresolved or as up-to-date. @ben-manes, any thoughts?

[jochenberger]

The problem with the Map lookup is that http://gradle.org/docs/current/javadoc/org/gradle/api/artifacts/ModuleVersionIdentifier.html#getGroup%28%29 seems to work differently as https://gradle.org/docs/current/javadoc/org/gradle/api/artifacts/Dependency.html#getGroup%28%29.

[ben-manes]

I prefer listing it as unresolved rather than up-to-date. It highlights that we can't intelligently evaluate that dependency, as flatDir may contain jars that really are out of date compared to Maven Central.

I think if we ignored file-based repositories that would cause the dependency to be unresolved in the report. Whether to explicit check or be indirect comes down to a personal preference of what appears cleaner and more obvious in the code. I like the assertion that we need a Spock test case no matter what happens.

[Rainer-Lang]

Any news? I have also this problem.

[ben-manes]

Can you put together a sample project demonstrating this bug?

[scompt]

@ben-manes Here's a link to the example again: https://www.dropbox.com/s/vr8xrzr739ng3ab/npe_example.tar.gz?dl=0

[ben-manes]

Thanks, I'll take a look at this next week.

[ben-manes]

The flatDir repositories are now being ignored since they don't contain metadata. A partial declaration (like in the sample) is listed as unresolved and a full declaration may find updates on a remote repository.

This was the least invasive way to fix this. I'm not familiar with the code since the rewrites to add type safety and json/xml reporters, so this seemed like the best approach.

[dodgex]

any eta for an release of this fix?

[ben-manes]

I'll take a look at integrating #59 tonight, which may be a better fix than mine. I'll also try to add a unit test to see if I can validate that.

@jochenberger has been handling the releases from his Bintray account, so we'll see if he has some time this week to kick one off.

[dodgex]

Thank you for your feedback! :)