Where to store passwords / credentials in Gradle Project

Problem Statement

Projects are checked in version control systems like git. You don’t want your credentials to be checked in git too. As such you need a way to easily inject your credentials in your build while keeping it away from prying eye.


The solution is to store it in ~/.gradle/gradle.properties. This file is not checked in and can be used across all your projects.

Recommendation: Private / Corporate Maven Repository: Sonatype Nexus or jFrog Artifactory


  • I am writing several reusable libraries which need to refer each other in myriad ways, each may be worked upon by different developer.
    • I don’t want to create a jumbo project with sub-modules where access control is a pita.
  • I don’t want the repository to be publicly accessible.
    • There should be fine-grained access control
  • I want to publish them as I would to maven central.
  • Ideally, it should also proxy maven central so I don’t have to use multiple repositories.
  • I want to install it in a lxd container behind haproxy (may write about the configuration in another post).
  • In short a sweet solution for most corporates.


The solution is to use a repository manager like Nexus or Artifactory. I prefer open source versions to start with.

So what are the good choices?

jFrog Artifactory

I downloaded the open source version and tried installing it. It was slow, very slow and confusing. There were myriad errors, the installation was complicated. In short, if I found it confusing inspite of copious documentation), you are very likely to. After couple of hours I decided it was not worth the pain.

Sonatype Nexus

Downloading was simple, running it was simpler. I installed it as systemd service. Only changes I had to do were:

  • Change user in nexus.service to ubuntu (default user in lxd)
  • Add one extra header in haproxy backend configuration:
    http-request set-header X-Forwarded-Proto https


Only few changes were required to get Nexus up and running.

  • Removed anonymous access
  • Deactivated anonymous user
  • Changed admin password and added users

It works well with gradle and well documented. Best part is that it is significantly faster and satisfies all my requirements.


The winner, for me, is Sonatype Nexus. It is fast, free, less cumbersome to install, setup and use. The default repositories serve my needs with minor tweaks.


Could the slowness of Artifactory be due to https to http conversion as I use haproxy for SSL termination?

That does not seem to be the case because I could load it properly, just slow.

OTH: Nexus was not loading properly till I passed X-Forwarded-Proto header.

How to rapidly test alternative ideas in Java during development


Java is a compiled language and in any non-trivial project you use multiple libraries which are neatly assembled for you when you run the application with your build system like gradle. This makes it hard and slow to test alternative ideas as you have to compile and run the project each time which is inconvenient and slow even in the best configuration.


Groovy is an interpreted language (can be compiled too for performance) and is a super-set of Java. It is ideally suited for testing alternative approaches while development. However, how do you include your runtime classpath so that it can access all your classes as well as third party libraries that you use?

There is a simple solution. You can add a task to your gradle build file. Here is a sample build file (build.gradle):

plugins {
    id 'groovy'
mainClassName = 'com.taragana.App'
dependencies {
    compile 'org.codehaus.groovy:groovy-all:2.4.14'
repositories {
task(console, dependsOn: 'classes', type: JavaExec) {
   main = 'groovy.ui.Console'
   classpath = sourceSets.main.runtimeClasspath

This build file contains the task console which can be run with:

gradle console

In the console you can import and access any of your existing class files as well as third party libraries that you included in the application.

Value Addition

This is also an instant test environment that you can use to test your tests before codifying them in test classes. This saves tremendous amount of time not only in coding but also in developing test cases.