Buildship - Credentials for distributionUrl not read from gradle.properties

Henriettel · February 19, 2018, 8:58am

OS: Ubuntu 16.04
Gradle Version: 4.4.1
Gradle User Home: /opt/gradle/gradle-4.4.1
Java Home: /usr/lib/jvm/java-8-oracle
Eclipse Version: Oxygen.2 Release (4.7.2)
Eclipse Build id: 20171218-0600
Eclipse Buildship: 2.2.1.v20180125-1441

Hi,
in my project in the gradle-wrapper.properties the distributionUrl points to an internal artifactory server where the gradle zip can be downloaded.
The server requires authentication with username/password which is set in the gradle.properties file in GRADLE_HOME (or is it GRADLE_USER_HOME?)
Anyway - it works when i call ./gradlew help in the command line, the gradle zip will be downloaded, the credentials in /opt/gradle/gradle-4.4.1/gradle.properties were used.

The behaviour in eclipse is different. The same project is used. Gradle distribution in eclipse’ gradle settings is set to Gradle wrapper
If i click on Gradle -> Refresh Gradle Project the refresh fails with Could not install Gradle distribution from <theURL> - Server returned HTTP response code: 401 for <theURL>
This is the stacktrace:

org.gradle.tooling.GradleConnectionException: Could not install Gradle distribution from ‘https://artifactory.network.local/artifactory/gradle-4.4.1.zip’.
at org.gradle.tooling.internal.consumer.DistributionFactory$ZippedDistribution.getToolingImplementationClasspath(DistributionFactory.java:137)
at org.gradle.tooling.internal.consumer.loader.CachingToolingImplementationLoader.create(CachingToolingImplementationLoader.java:40)
at org.gradle.tooling.internal.consumer.loader.SynchronizedToolingImplementationLoader.create(SynchronizedToolingImplementationLoader.java:43)
at org.gradle.tooling.internal.consumer.connection.LazyConsumerActionExecutor.onStartAction(LazyConsumerActionExecutor.java:101)
at org.gradle.tooling.internal.consumer.connection.LazyConsumerActionExecutor.run(LazyConsumerActionExecutor.java:83)
at org.gradle.tooling.internal.consumer.connection.CancellableConsumerActionExecutor.run(CancellableConsumerActionExecutor.java:45)
at org.gradle.tooling.internal.consumer.connection.ProgressLoggingConsumerActionExecutor.run(ProgressLoggingConsumerActionExecutor.java:58)
at org.gradle.tooling.internal.consumer.connection.RethrowingErrorsConsumerActionExecutor.run(RethrowingErrorsConsumerActionExecutor.java:38)
at org.gradle.tooling.internal.consumer.async.DefaultAsyncConsumerActionExecutor$1$1.run(DefaultAsyncConsumerActionExecutor.java:55)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
at java.lang.Thread.run(Thread.java:748)
at org.gradle.tooling.internal.consumer.BlockingResultHandler.getResult(BlockingResultHandler.java:46)
at org.gradle.tooling.internal.consumer.DefaultModelBuilder.get(DefaultModelBuilder.java:50)
at org.gradle.tooling.internal.consumer.DefaultProjectConnection.getModel(DefaultProjectConnection.java:41)
at org.eclipse.buildship.core.workspace.internal.ConnectionAwareLauncherProxy.newModelBuilder(ConnectionAwareLauncherProxy.java:64)
at org.eclipse.buildship.core.workspace.internal.DefaultModelProvider.fetchModel(DefaultModelProvider.java:68)
at org.eclipse.buildship.core.workspace.internal.DefaultModelProvider.supportsCompositeBuilds(DefaultModelProvider.java:165)
at org.eclipse.buildship.core.workspace.internal.DefaultModelProvider.fetchModels(DefaultModelProvider.java:75)
at org.eclipse.buildship.core.workspace.internal.DefaultModelProvider.fetchEclipseGradleProjects(DefaultModelProvider.java:99)
at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildsJob.fetchEclipseProjects(SynchronizeGradleBuildsJob.java:91)
at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildsJob.synchronizeBuild(SynchronizeGradleBuildsJob.java:81)
at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildsJob.runToolingApiJob(SynchronizeGradleBuildsJob.java:73)
at org.eclipse.buildship.core.util.progress.ToolingApiJob$1.run(ToolingApiJob.java:73)
at org.eclipse.buildship.core.util.progress.ToolingApiInvoker.invoke(ToolingApiInvoker.java:62)
at org.eclipse.buildship.core.util.progress.ToolingApiJob.run(ToolingApiJob.java:70)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
Caused by: java.io.IOException: Server returned HTTP response code: 401 for URL: https://artifactory.network.local/artifactory/gradle-4.4.1.zip
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1894)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:263)
at org.gradle.wrapper.Download.downloadInternal(Download.java:66)
at org.gradle.wrapper.Download.download(Download.java:51)
at org.gradle.tooling.internal.consumer.DistributionInstaller$1.run(DistributionInstaller.java:128)

This is the gradle.properties file:

systemProp.artifactory_user=SomeUser
systemProp.artifactory_password=someAPIKEy39f067c70513193ae86f6a83507b131173e57332ac2c096e71
systemProp.gradle.wrapperUser=SomeUser
systemProp.gradle.wrapperPassword=someAPIKEy3f067c70513193ae86f6a83507b131173e57332ac2c096e71
org.gradle.parallel=false

donat · February 19, 2018, 3:27pm

Hi,

The wrapper username and password values are loaded as JVM arguments when the wrapper download starts. This is different in Eclipse where Buildship and Eclipse share the same VM. Buildship doesn’t modify the system properties, causing your build to fail.

You can fix the problem by declaring your proxy settings in the Eclipse preferences. Or, you can work around the problem by specifying the proper JVM arguments in the eclipse.ini file.

Henriettel · February 21, 2018, 1:42pm

Hi,

thanks for your answer although this is not sufficient for me as i don’t want to edit the users eclipse.ini.
What if i put username und password into the GRADLE_OPT variable inside the gradlew script of the project?
Will the gradlew script be used to download the binary?

Henriettel · February 26, 2018, 10:19am

OK, adding username and password to GRADLE_OPTS in gradlew does not work:
GRADLE_OPTS=$GRADLE_OPTS" -Dgradle.wrapperUser=SomeUser -Dgradle.wrapperPassword=someAPIKEy3f067c70513193ae86f6a83507b131173e57332ac2c096e71"

works if you start the gradlew from commandline but it does not work if you click on Refresh Gradle Project although Gradle wrapper is used as Gradle distribution in the projects’ settings.

crosscontrol · March 9, 2018, 10:35pm

Hi,

It looks like I’m having the same issue. I’m trying to get our custom gradle distribution init scripts to pick up system properties that are set in the gradle.properties file (the Buildship preferred way).

For example:
systemProp.credentialWrapperUsernameKey=myUsername

These system properties are picked up when run from the command line and the project builds as expected.

As an aside, for our IntelliJ users, we were able to set gradle VM options as a work around for what I assume is the same problem.

It seems like the older version of Buildship would have allowed the user to add these properties manually (not ideal but at least it would work). I wonder if it is possible for Buildship to parse a project’s gradle.properties file and make “systemProp” properties available to builds. Its not ideal but maybe something like that could work for this problem (if you don’t want to bring back allowing variables to be set manually)?

Since Buildship states to use the gradle.properties file for these settings, should we open an issue for this problem?

Thanks to the developers for the great work with Gradle and Buildship!

donat · March 14, 2018, 2:28pm

We used to have those options, but they would not solve the problem/ The passed arguments are only picked up by the JVM, a separate process downloads the wrapper. IDEA presumably works the same way. I tried specifying wrapper credentials, but they were ignored for the download.

crosscontrol · March 15, 2018, 11:14pm

Thanks for the reply! For my situation, the wrapper is stored on a public repository (bintray) and doesn’t require credentials to download. When the wrapper is extracted and run, the init scripts inside of the wrapper are actually what need the properties.

In IntelliJ, you are able to pass the system properties via “-D”. I’ve verified this works (not my actual information, obviously):

I don’t know what the difference is but it works there. I have verified it also works by modifying the eclipse.ini file and placing them after vmargs like so:

...
-vmargs
-DcredentialWrapperUsernameKey=myUsernameKey
-DcredentialWrapperPasswordKey=myPasswordKey
...

Modifying eclipse.ini or even the way we have to do it in IntellJ isn’t ideal as it forces each user to do something different in the IDE versus what they would do on the command line. If we could get it to grab the properties from the gradle.properties file, I think that would be preferable. Having the option via the Buildship GUI would be second, and modifying eclipse.ini is third, in my humble opinion.