Troubleshooting

This page contains suggestions for how to recognise and fix common problems using Gradle, the Holy Gradle, and Artifactory.

Gradle Command-Line Options

Gradle has many command-line options, some of which are useful for diagnosing or working around problems.

--help (-h, -?)

Shows all the options.

--system-prop (-D)

Defines a Java system property.

--project-prop (-P)

Defines a Gradle project property.

--info (-i) or --debug (-d)

Output extra logging. These can generate a lot of output, so it may be helpful to redirect the output to a file. In order to capture "standard error" as well as "standard output", use 2>&1, as described on the Support page.

Warning

These log messages may contain passwords sent to Artifactory.

--stacktrace (-s) or --full-stacktrace (-S)

Outputs a Java stack dump when an exception is thrown, which can help plugin developers understand problems. The default behaviour is to output only the exception message.

--dry-run (-m)

Shows the tasks which would be run in response to a given command line, without actually running them. This can also be useful to check the order in which commands would run.

--offline

Forces Gradle not to make any network connections, and only use its local cache. This may be necessary if you’re working off-line, and may help performance if you’re working over a slow connection, such as a VPN. If your local cache does not already contain all the modules you need, this option may cause problems.

--no-color

Removes the colour-coding of the output.

To change the colour of the console output, see this post. For example, set GRADLE_OPTS to something like the following. You can’t specify exact RGB values; you have to use one of the predefined colors.

-Dorg.gradle.color.description=MAGENTA

--no-daemon

Runs without the Gradle daemon.

--stop

Stops the background Gradle daemon if it is running. In rare cases this may be needed if the daemon process has a lock on files you want to delete.

You can add any of these options to the GRADLE_OPTS environment variable if you want them permanently set. For example, this may be useful for --no-color.

Accessing Artifactory

Artifactory URL

URLs are used to access Artifactory in three ways. If URLs are wrong in any of these places you may get the following errors.

java.net.ConnectException

404 Not Found

The custom Gradle wrapper uses a URL to download the Holy Gradle plugins. From version 7.0.0 the wrapper gets this URL from the environment variable (HOLY_GRADLE_REPOSITORY_BASE_URL), which should be set to a site-specific value. From 7.5.0 of the Gradle wrapper it can be set up automatically using a DNS lookup file in your project’s source code. See Setting up a Gradle Wrapper and Accessing Artifactory for details.
Your build.gradle script will use a URL in the repositories section to point to the repositories where your project's dependencies can be found.
Your build.gradle script may also use a URL in the publishPackages section to say where to publish your module.

Passwords and Permissions

The Holy Gradle sends passwords to Artifactory and to source control repositories to get the dependencies for your project. If these passwords are wrong, or you do not have the permissions to access them, you may get errors as shown below.

Incorrect Password

If your username and/or password are sent incorrectly to Artifactory, or not sent at all, you will get an error message including

401 Unauthorized

for example:

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':publishIvyPublicationToIvyRepository'.
> Failed to publish publication 'ivy' to repository 'ivy'
   > java.io.IOException: Could not PUT
'https://artifactory.example-corp.com/artifactory/teamA-integration-local/com.example-corp.teamA/MyLib/0.0.0/MyLib-buildScript-0.0.0.zip'.
Received status code 401 from server: Unauthorized

This can happen for any of these reasons.

You have not supplied a credentials block for some repositories. See the documentation for my-credentials-plugin for how to do this. Note that the credentials for dependency repositories and for publishing repositories must be specified separately.
Your username and password are not stored in the Windows Credential Manager. You may need to run gw.bat with the --no-daemon argument to allow the password prompt dialog to be shown. See the my-credentials-plugin page for more information.
Your username and password are stored in the Credential Manager but the password is out of date. See the my-credentials-plugin page for information on how to update it.
You have a username and password stored in the Credential Manager, but that username does not have an account on your Artifactory server. Please contact the appropriate person from the Support page to check this. Note that the stored username is normally the same as your Windows login name, but it can be set to a different username.
Your Artifactory server is configured only to accept encrypted passwords but you have stored your password unencrypted, or the other way round. Normally encrypted passwords are used if your server has an http: URL, otherwise your normal, unencrypted password is used. Please contact your support person to check.

Incorrect Artifactory Permissions

If you have the correct credentials but you do not have permission to fetch files from or publish files to a certain path in Artifactory, you will get an error message containing

403 Forbidden

If you know which repositories you need access to, please contact the appropriate person from the Support page to request access. It is good practice also to "CC:" the person who runs the team which owns that repository.

If you are not sure which repositories are causing the problem, please send the complete output of your command, plus your build.gradle and gradle.properties, to the appropriate support contact.

If you see a specific URL in the error message, it’s useful to send it in your support request, but the permission problem may or may not be with that URL. This is because of how a virtual repository works in Artifactory. A single URL is used to search a list of other paths. If the files you need are under a path in the middle of the list, but you don’t have permissions to access it, you may get an error about the last path in the list, even though that’s not relevant.

Accessing Mercurial

DONE: https://bitbucket.org/nm2501/holy-gradle-plugins/wiki/HolyGradleCookbook#!mercurial

Mercurial Passwords

To access passwords stored in the Windows Credential Manager, Mercurial uses an extension called mercurial-keyring. The Holy Gradle relies on this extension being enabled. See http://mercurial.selenic.com/wiki/UsingExtensions for details of how to enable extensions in your mercurial.ini file, and http://mercurial.selenic.com/wiki/KeyringExtension for the mercurial-keyring extension itself. You can also control extensions in the TortoiseHg GUI.

The extension allows passwords to be saved securely but another piece of configuration controls when Mercurial will try to send a username and password to a repository. Without this, Mercurial will not use your username and password, even if they are stored. This configuration is the auth section of the mercurial.ini file.

The intrepid-plugin uses the username and password for a repository according to what was saved by the mercurial-keyring extension. If no password has already been saved, intrepid will pre-load it with the "Domain Credentials" from the my-credentials-plugin. If the password used by that plugin is out of date, you may get a error saying that you are unauthorized. See the my-credentials-plugin for how to update your password.

Mercurial HTTPS Access

Some Mercurial repositories within organisations use https: URLs but have SSL certificates which are not signed by a public certificate authority. This means that Mercurial will not trust them by default. If you have sourceDependencies pointing to such servers, you will get errors like the following.

certificate not verified

abort: error: _ssl.c:490: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

One way to fix this in Mercurial is to add the certificate to a web.cacerts file, as described at http://mercurial.selenic.com/wiki/CACertificates. However, before release 7.3.0 the Holy Gradle used its own bundled version of Merurial which would ignore the web.cacerts file set up in that way. If you try to use this method with an older version of the Holy Gradle, you will get an error like the following.

abort: could not find web.cacerts: C:\temp\Mercurial251\cacert.pem

Instead you should upgrade and/or use Host certificate fingerprints.

Finding Modules

How do I find which versions of module M are available?

Use the Artifactory "Simple Browser" to browse the appropriate virtual repository. Ask the team which published it to tell you which repository to look in, if you are not sure. See … get something from Artifactory for more information.

How do I get version X of module M into my project?

Ask the team which published the module to tell you the name of the repository you should get it from. This should be a virtual repository, because the names of local or remote repositories may be changed by administrators in future, but those of virtual repositories should stay the same.

If the repository is not already in your build.gradle file, add it, along with any credentials (username and password) needed to access it. See repositories for details.

Then add an entry to the packedDependencies section to reference the module vesion. See packedDependencies for details.

What do I do if I have a version conflict?

If two different versions of the same module are included in your dependencies, directly or indirectly, you may get an error like this.

* What went wrong:
Could not resolve all dependencies for configuration ':everything'.
> A conflict was found between the following modules:
   - com.example-corp.teamA:base-lib:1.2.8
   - com.example-corp.teamA:base-lib:1.2.4

To resolve this sort of problem, see Fetch Dependencies.

How do I get module version M:X from a remote server to my site’s server?

Normally you should not need to do anything for this to happen. Your site’s Artifactory administrators will have configured one or more virtual repositories at your site to point to remote repositories (also at your site) which cache module files from another site. When you request the module (by adding it to your build.gradle and running gw fAD), it will be transferred automatically to your site.

If this does not happen, please contact your Support staff and give them as much information as possible. There could be several reasons.

It may be that nobody has needed files from that repository at the other site before, so your administrators will have to create a new remote repository. This can be done quickly.
It may be that you do not have permission to access that remote repository. Permissions can be changed quickly, although there may be policies between sites to control access, which may make this slower.
If the module is very large and/or your site’s connection to the other site is slow, your Gradle build may time out before the files are transferred. If you send a detailed log file including the time when you tried to build, your support staff can check for this in the Artifactory log files.