Trying to create "safe" property access

(Patrick Heck) #1

I’m facing this issue: wherein the build seems to be getting null for the credentials and apparently that’s not handled gracefully by gradle. So as a workaround I tried:

private String safeDefaultProp(String prop, someDefault) {
  if (project.hasProperty(prop)) {
    return project.getProperty(prop)
  } else {
    if (someDefault) {
      return someDefault
    } else {
      return ""

The idea being that this can’t return null, and fresh checkouts by folks who are not commiters (myself only for now) should be using anonymous access anyway. However the above code along with:

buildscript {
  repositories {
    maven {
      credentials {
        username = safeDefaultProp("jj_artifactory_user", System.env.ARTIFACTORY_USER)
        password = safeDefaultProp("jj_artifactory_password", System.env.ARTIFACTORY_PASSWORD)

gives the following error:

* What went wrong:
A problem occurred evaluating root project 'ingest'.
> Could not find method safeDefaultProp() for arguments [jj_artifactory_user, null] on Credentials [username: null] of type org.gradle.api.internal.artifacts.repositories.DefaultPasswordCredentials_Decorated.

And before you ask, the reason there are two levels of defaulting required is that 1 is for human commiters and the other is for TravisCI

(Patrick Heck) #2

I should have mentioned: this is gradle 3.3 and I’m stuck there for the moment because of a plugin that doesn’t work in newer versions (, so I may possibly be running into a bad handling of null that is already fixed, but “upgrade” isn’t an easy answer. I need a workaround.

(Patrick Heck) #3

Also, I’ve already tried making it public or making it public static and passing in project… and using def (static and not static) … and this.safeDefaultProp (error complains about not finding it on project rather than configuration)

(James Justinic) #4

The buildscript block is special because it contributes to the classpath of the rest of the build script. It is compiled and executed first in isolation, so you can’t reference a method declared in the regular body of the build script.

If the repository allows anonymous read access, why do you care about non-anonymous access for the buildscript block?

(Patrick Heck) #5

Because as maintainer sometimes I need to deploy to the repo which is not allowed for anonymous users.

(James Justinic) #6

I don’t think you understood my question. I absolutely expect for your build to have a way for maintainer to externally specify credentials for the publishing repository. Other users will not have write access.

I’m asking why you’re trying to specify credentials for repository configurations that can only be used for resolving dependencies (i.e. the buildscript block repositories).