Gradle build breakage with 3.3.1 release - ${env.ANDROID_HOME}

[extensia]

I recently upgraded a Java server application to 3.3.1 and am seeing the following error messages when resolving dependencies. It appears the system paths containing ${env.ANDROID_HOME} are causing issues with gradle. We are using gradle 4.2.1 with the following dependencies:

compile('com.google.zxing:core:3.3.0')
compile('com.google.zxing:javase:3.3.0')

Task :compileJava
Errors occurred while build effective model from C:\Users\eXtensia.gradle\caches\modules-2\files-2.1\com.google.zxing\core\3.3.1\d1e7c4667f9dcdda30d09f3df7d1b44f65c44336\core-3.3.1.pom:
'dependencyManagement.dependencies.dependency.systemPath' for com.google.android:android:jar must specify an absolute path but is ${env.ANDROID_HOME}/platforms/android-22/android.jar in com.google.zxing:core:3.3.1
Errors occurred while build effective model from C:\Users\eXtensia.gradle\caches\modules-2\files-2.1\com.google.zxing\javase\3.3.1\357121cdf3f89f63ddfaad18170612dcad0db947\javase-3.3.1.pom:
'dependencyManagement.dependencies.dependency.systemPath' for com.google.android:android:jar must specify an absolute path but is ${env.ANDROID_HOME}/platforms/android-22/android.jar in com.google.zxing:javase:3.3.1

[srowen]

The build uses maven, not Gradle, and that works fine.

[extensia]

The issue is that something in the POM is causing build problems for gradle projects consuming the Maven artifacts. I expect other users will encounter this issue since Gradle is widely used these days as an alternative to Maven.

The problem started with the latest release and appears to be due to a change in the artifact packaging. Rolling back to the previous release fixes the problem.

I am not familiar with the requirements for Android usage, but it seems that the POM was built assuming ${env.ANDROID_HOME} variable is defined which is certainly not the case for non-Android development environments. Gradle is unhappy since it is seeing the undefined variable in the systemPath for both artifacts.

[srowen]

You're building your own project with Gradle, not this one?
OK, though env.FOO is always the standard way of access env variables in Maven. Some of the build is only enabled when ANDROID_HOME is set. It shouldn't affect anything otherwise. I'm guessing Gradle doesn't understand the profile activation or env variables or both.

[extensia]

Correct. We are using ZXing as dependency for a gradle build.

I believe your assessment of the problem is correct. While there is a growing overlap between gradle and maven functionality, interoperability is mainly at the artifact level. Gradle handles transitive dependencies and parent POMs well, but does not implement any of the maven build logic since it has its own groovy-based DSL and project model..

This sort of breakage is very unusual and not something we have seen in over 10 years of working with gradle.

[extensia]

I see you have closed the issue. Is this something that can be addressed? We are using ZXing barcode functionality and were looking to implement some of the recent bug fixes.

[extensia]

I did a little more digging. The error is actually a Spring Boot interoperability issue. The message is coming from the following Spring gradle plugin code which is analyzing the zxing POM.

https://github.com/spring-gradle-plugins/dependency-management-plugin/blob/master/src/main/java/io/spring/gradle/dependencymanagement/internal/maven/EffectiveModelBuilder.java

[srowen]

Can you manually disable the profile that enables the Android modules?

[extensia]

I don't believe so. The Spring Boot plugin makes use of master POM info to automatically pull in default versions for its supported frameworks. This allows the project to omit the version number of supported dependencies and automatically default to the versions tested with the current Spring Boot release.

I believe the plugin is processing the POM files for all project dependencies and is choking on zxing since the environment variable value is unknown. I considered defining the Android home variable, but that would require it to be set across our build environment and at customer sites using our libraries due to transitive dependencies.

The Spring Boot developers could presumably fix the issue, but that will not be a speedy process since we would need to wait for the issue to be fixed and for the next release.

[srowen]

Does it help if the POM declared <android.home>${env.ANDROID_HOME}</android.home> as a property and then just used the property? Presumably it'd have the same kind of problem.

The error is actually kind of narrow, just noting that ${env.ANDROID_HOME}/... isn't obviously an absolute path starting with "/", and Maven knows that can't be right for a systemPath. I could add that prefix because it really has to be absolute and the result would just be a path like "//path/to/android". Do you have any way of checking that? I am kind of afraid you'd just find something else fails to evaluate.

[extensia]

It is hard to say if that will work without diving into the Spring Boot plugin design.

[extensia]

Here is a minimal gradle project that demonstrates the issue if you want to experiment. The project consists of two files: build.gradle in the project folder and a dummy class in the src/main/java.

test.java (located in ./src/main/java/test.java)

public class test {
}

build.gradle (located in ./build.gradle)

plugins {
id 'java'
id 'org.springframework.boot' version '1.5.8.RELEASE'
}

repositories {
mavenCentral()
}

dependencies {
compile('org.springframework.boot:spring-boot-starter')
compile('com.google.zxing:core:3.3.1')
}

defaultTasks 'build'

bootRepackage {
enabled = false
}

[srowen]

I added the redundant leading slash mentioned above. That should at least cure the exact error you see there. Don't know if it means others crop up.

You could test by downloading the master source, mvn -DskipTests install, then try building vs version "3.3.2-SNAPSHOT". That should find the local version with this change.

[mlaccetti]

@extensia Did you try out the 3.3.2-SNAPSHOT build? Curious to see if it fixed it.

[rohanliston]

@mlaccetti I just tried it. The warning goes away and everything seems to work OK 👍

@srowen Will there be a 3.3.2 release to Maven Central anytime soon?

[srowen]

I could do another release shortly. Let me back up and see if there are any other changes that need to get it.

[HSKC]

I still got the Warning with 3.3.2

Processing of C:\Users\dwi\.gradle\caches\modules-2\files-2.1\com.google.zxing\javase\3.3.2\2a2225f48c4e3caccfe1de121156480b16055b3b\javase-3.3.2.pom failed:
    'dependencyManagement.dependencies.dependency.systemPath' for com.google.android:android:jar must specify an absolute path but is /${env.ANDROID_HOME}/platforms/android-22/android.jar in com.google.zxing:javase:3.3.2
Processing of C:\Users\dwi\.gradle\caches\modules-2\files-2.1\com.google.zxing\core\3.3.2\9bef844add16a35db6636825c54e1e84cc560316\core-3.3.2.pom failed:
    'dependencyManagement.dependencies.dependency.systemPath' for com.google.android:android:jar must specify an absolute path but is /${env.ANDROID_HOME}/platforms/android-22/android.jar in com.google.zxing:core:3.3.2

[srowen]

I suspect it's because you're using Windows paths, and the hard-coded separator that's supposed to resolve this is Linux-style. Try using Linux paths? I kind of thought the build tools would still interpret them as expected on Windows.

[chrisptree]

Is there any workaround for Windows users? I tried to change the environment variable ANDROID_HOME to /Users/<user name>/AppData/Local/Android/Sdk without functional result. I still have the error when I try to compile CAS Apereo.

Errors occurred while build effective model from C:\Users\<user name>\.gradle\caches\modules-2\files-2.1\com.google.zxing\core\3.3.2\9bef844add16a35db6636825c54e1e84cc560316\core-3.3.2.pom:
    'dependencyManagement.dependencies.dependency.systemPath' for com.google.android:android:jar must specify an absolute path but is /${env.ANDROID_HOME}/platforms/android-22/android.jar in com.google.zxing:core:3.3.2

[nathangs]

I've run into the same issue trying to run Apereo CAS on a Windows machine with rest auth enabled:

compile "org.apereo.cas:cas-server-support-rest-authentication:${project.'cas.version'}"

The error:

C:\inetpub\sites\ExternalApplication\cas-gradle-overlay>gradlew bootRun

> Task :cas:bootRun FAILED
Errors occurred while build effective model from C:\Users\<USER-PROFILE>\.gradle\caches\modules-2\files-2.1\com.google.zxing\core\3.3.2\9bef844add16a35db6636825c54e1e84cc560316\core-3.3.2.pom:
    'dependencyManagement.dependencies.dependency.systemPath' for com.google.android:android:jar must specify an absolute path but is /${env.ANDROID_HOME}/platforms/android-22/android.jar in com.google.zxing:core:3.3.2

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':cas:bootRun'.
> A problem occurred starting process 'command 'C:\Program Files\Java\jdk1.8.0_181\bin\java.exe''

[srowen]

Hm, if you manually edit the pom.xml file to use a backslash in that path, does it work? if so I wonder if we can reference the platform file separator here rather than hard code a slash? @nathangs

[nathangs]

Sean, thank you for getting back to me so quickly. I tried your suggestion to change the slashes to backslashes on line 722 of C:\Users<USER-PROFILE>.gradle\caches\modules-2\files-2.1\com.google.zxing\zxing-parent\3.3.2\4ad323c509da2eff69fe7f02ef0f4e5910509206\zxing-parent-3.3.2.pom:

<systemPath>\${env.ANDROID_HOME}\platforms\android-${android.platform}\android.jar</systemPath>

Unfortunately this didn't work and I got the same error message about an incorrect absolute path.

However, I did find something interesting: I was able to get CAS working by running gradlew build then gradlew run without issue. I still see the absolute path error message when running these commands but it doesn't prevent CAS from running like the gradle bootRun command. Perhaps this is problem with the gradle bootRun task that's a part of the CAS project?

[srowen]

What is CAS? is it related to android? you don't have to build any of the Android stuff if you don't want it. Did you set ANDROID_HOME?

[nathangs]

chrisptree and I are both using Apereo CAS. It doesn't have anything to do with Android as far as I can tell. They recommend using a WAR overlay deployment method that uses a maven or gradle script to download any needed dependencies (zxing being one of them) then builds the CAS application along with customizations you have made.

I have the Android 22 SDK installed and the ANDROID_HOME environment variable set to C:\android-sdk. I rebooted my PC after adding the variable. Android.jar exists at this path which I believe is what zxing is looking for:

C:\android-sdk\platforms\android-22\android.jar

[srowen]

Oh right, per above, maybe Gradle doesn't parse the bit that says to skip the Android parts unless ANDROID_HOME is set. You can just chop the modules out of your build manually, too.

[qianggetaba]

If some one else got the same problem, you could try this

[timguy]

If I could I would reopen.
I see no way to fix this from gradle side.
Somehow this profile "build-android" needs to be deactivated. Maybe only activate if some property is set? But than probably android users will complain ;-).

Workarounds

• can not use @qianggetaba workaround because it has to be done manually on every machine and will only work for me and not on colleagues pc or build server.
• will go the workaround with the old version 3.3.0. It's also the version with the most usages according to maven central. maybe this is one of the reasons? All tutorials also show this version.

[srowen]

3.3.0 was (IIRC) the last Java 7 version, I don't know. Surely you can at worst just remove this profile, or hard-code activating it? Maven lets you disable profiles with -P!profile syntax; can you enable/disable on the command line with Gradle the same way if needed?

[timguy]

thanks for fast reply. The maven command line won't help me here because I can not get this done with gradle.
I asked in stackoverflow as well how to deactivate a profile.

There are 2 conditions for the build-android profile:
In my case ANDROID_HOME is not set but JDK 8 is used. ? Mhh just saw it changed in maven since 3.2.2 from OR to AND: maven.apache.org/pom.html#Activation But anyway. Seems gradle is not interested in that and just use the profile. Seems only 2 types of activations (activeByDefault, active on the absence of a system property) are considered by gradle (blog.gradle.org/maven-pom-profiles)
On that page it is considered as "Such a practice is considered to be an anti-pattern to be avoided as it influences the reproducibility of a build." ;-). But I don't know maven to suggest something to make android users happy. I don't know how it was solved before or which extra steps the android users had to take.

[srowen]

I mean, I could make the profile 'opt-in' by removing the activation. That's no big deal. But I don't see why you would not just remove the profile if you need to deactivate it in Gradle? just edit pom.xml

[timguy]

I mean, I could make the profile 'opt-in' by removing the activation.

that would be great.

But I don't see why you would not just remove the profile if you need to deactivate it in Gradle? just edit pom.xml

Of course I can modify the pom.xml. But the issue is I have to do it again and again manually whenever I clean or build new. Gradle is resolving the dependencies. I just delcare compile('com.google.zxing:core:3.3.1') and thats it. The pom is downloaded and the dependencies (like the parent zxing-parent) are resolved and fetched automatically. If you use gradle as it is you never see the pom. You can also see in this ticket that the poms are somewhere stored in caches and controlled by gradle:
C:\Users\eXtensia.gradle\caches\modules-2\files-2.1\com.google.zxing\core\3.3.1\d1e7c4667f9dcdda30d09f3df7d1b44f65c44336\core-3.3.1.pom

The biggest disadvantage would be that I can not run a build on a build server (like jenkins) because I have no chance to interrupt between the pom download and the compile.

[scibuff]

this is still an issue in 3.5.0

[pabsures]

Errors occurred while build effective model from C:\Users\user.gradle\caches\modules-2\files-2.1\com.google.zxing\core\3.5.0\d23101cb84e79a015b8ffd0b51b8cebfe27d1a1c\core-3.5.0.pom:
'dependencyManagement.dependencies.dependency.systemPath' for com.google.android:android:jar must specify an absolute path but is /${env.ANDROID_HOME}/platforms/android-22/android.jar in com.google.zxing:core:3.5.0

@srowen this still exist in 3.5.0

[srowen]

Folks: read above. There is no problem with the Maven build. This is a Gradle issue if anything in how it reads POMs. You can edit the POM if you want.

[extensia]

Strange this continues to be a source of problems. I am using the 3.5.0 core and javase artifacts in a Java server project using Gradle 7.4.2. The problem I originally reported appears to have been resolved. Here is my dependency declaration for reference.

api('com.google.zxing:javase:3.5.0')

Depending on your requirements you might also consider using Okapi Barcode. It is actively maintained and supports many barcode formats.

https://github.com/woo-j/OkapiBarcode

[timguy]

@srowen No the gradle users can't edit the POM because everything is handled by gradle from this point. Manually for every build yes but not possible in build integration tools to interrupt in this process. (see my comment here: #904 (comment))
To depend on environment is also a bad practice if you want to have reproduceable builds (https://dzone.com/articles/maven-profile-best-practices)

Your suggestion here would help:

I mean, I could make the profile 'opt-in' by removing the activation. That's no big deal. But I don't see why you would not just remove the profile if you need to deactivate it in Gradle? just edit pom.xml

[srowen]

Would it not be more productive to lobby Gradle to support this aspect of POM files? This will be a problem for Gradle for more than this project. Just seems like the wrong place to pursue