Settings.gradle not finding properties from gradle.properties

issue-resolved
gradle-3505

(Hoobajoob) #1

Problem

I’m getting this error message in a 2.14 project:

FAILURE: Build failed with an exception.

* Where:
Settings file 'E:\dev\myProject\settings.gradle' line: 3

* What went wrong:
A problem occurred evaluating settings 'myProject'.
> Could not get unknown property 'artifactoryBaseUrl' for object of type org.gradle.plugin.repository.internal.DefaultMavenPluginRepository.

Gradle Files

Here is settings.gradle:

pluginRepositories {
    maven {
        url "$artifactoryBaseUrl/libs-local"
        credentials {
            username mavenRepoUser
            password mavenRepoPassword
        }
    }
    maven {
        url "$artifactoryBaseUrl/plugins-release"
        credentials {
            username = mavenRepoUser
            password = mavenRepoPassword
        }
    }
    gradlePluginPortal()
}

Here is gradle.properties:

mavenRepoUser=myArtifactoryUser
mavenRepoPassword=myArtifactoryPassword
artifactoryBaseUrl=http://artifactory.service.net

Question

Why is settings.gradle not able to find properties defined in gradle.properties?

Observations

If I replace the property names in settings.gradle with their string literals, not only does the error go away, but these same properties are successfully resolved within build.gradle, which makes use of the same properties. So, it seems that only settings.gradle is having this problem.

Environment

Windows 8.1, jdk 1.8.0_u91 (64-bit)

build.gradle, settings.gradle, and gradle.properties are all co-located in the same project directory. I have no gradle.properties file in my user home directory.

I’m using the 2.14 gradle wrapper with this command line:

gradlew tasks

Here are the contents of MANIFEST.MF found in gradle/wrapper/gradle-wrapper.jar:

Manifest-Version: 1.0
Implementation-Title: Gradle
Implementation-Version: 2.14

Here are the contents of gradle/wrappper/gradle-wrapper.properties:

distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-2.14-bin.zip

(Francois Ritaly) #2

AFAIK the settings.gradle file is one of the very first evaluated by Gradle to detect the projects to build. This file tells Gradle what are the modules to build.

Unless I’m wrong, the gradle.properties file is only evaluated when evaluating the corresponding project.

So this means that you don’t have access to the properties defined in the gradle.properties when evaluating the settings.gradle file because this file is evaluated later in the kinematics


(Hoobajoob) #3

This seems different from the documentation for settings.gradle:

Using Settings in a Settings File

Dynamic Properties

In addition to the properties of this interface, the Settings object makes some additional read-only properties available to the settings script. This includes properties from the following sources:

  • Defined in the gradle.properties file located in the settings directory of the build.
  • Defined the gradle.properties file located in the user’s .gradle directory.
  • Provided on the command-line using the -P option.

(Hoobajoob) #4

I can also confirm that I do not see this error when attempting to reference properties defined in gradle.properties for projects using the 2.12 wrapper.

@mark_vieira: seems like this might be a defect in 2.14’s handling of the new pluginRepositories block. It only exhibits when there are property references in the pluginRepositories block. Property references outside the pluginRepositories block are resolved without error in 2.14.

That is, with this gradle.properties file:

someUrl=http://some-server.net

…this settings.gradle will produce an unknown property error for someUrl:

pluginRepositories {
    maven {
        url "$someUrl/libs-local"
    }
    gradlePluginPortal()
}
println "Here's someUrl: $someUrl"

…but this one will not:

pluginRepositories {
    maven {
        url "http://some-server.net/libs-local"
    }
    gradlePluginPortal()
}
println "Here's someUrl: $someUrl"

(Pepper Lebeck-Jobe) #5

The current state of the world is that this is “Not Working … As Intended.”

We are striving to make the pluginRepositories {} block as declarative as possible. That is, we want to be able to take advantage of performance optimizations and things which would require the data of the specification to cacheable (just as an example.)

We are likely to loosen the syntactic restrictions as we continue to develop the feature. But, since it is always easier to loosen than to tighten such restrictions, we’ve started out by being very conservative.

So, the actual nature of the issue is not that settings.gradle is not finding the properties in gradle.properties, but rather, that we are ignoring anything that might be volatile or dynamic in the pluginRepositories {} block. This is similar to the restrictions spelled out in this documentation about the plugins {} block.

However, by contrast, we don’t have such a thorough disclaimer about the constrained syntax in the documentation of the pluginRepositories block. I’m opening a bug for us to flesh out the documentation to help avoid this sort of confusion (at least until we do loosen the syntax.)

In the meantime:

  1. Can you workaround this problem by just hard-coding the value in the settings.gradle file?
  2. Can you tell me more about your use-case? Is it basically that you have different development and production plugin repositories?

I do want to be clear that this is exactly the sort of feedback we are looking for. We want to be reasonable about supporting our users needs but also making sure that we don’t introduce complexities that needlessly add complexity and hurt performance.


(Hoobajoob) #6

Thanks for the clarification - I agree that a documentation note on constraints in the pluginRepositories section would be great.

Can you workaround this problem by just hard-coding the value in the settings.gradle file?

I currently have this workaround in place:

pluginRepositories {
    // NOTE: gradle 2.14 doesn't recognize properties from
    //       gradle.properties in the pluginRepositories
    //       block. If this changes in a future revision,
    //       the variable def's below can all be deleted
    def mavenRepoUser = "myUser"
    def mavenRepoPassword = "myPassword"
    def baseUrl = "http://artifactory.service.net"

    maven {
        url "$baseUrl/libs-local"
        credentials {
            username mavenRepoUser
            password mavenRepoPassword
        }
    }
    maven {
        url "$baseUrl/plugins-release"
        credentials {
            username = mavenRepoPassword
            password = mavenRepoPassword
        }
    }
    gradlePluginPortal()
}

Can you tell me more about your use-case? Is it basically that you have different development and production plugin repositories?

@eljobe: Here, the interest in gradle.properties isn’t so much in the multiple repositories, it’s in defining repo configuration (the baseUrl, username, and password properties) in just one place so they can be used in multiple gradle files (settings.gradle and build.gradle in this case).

We do, at the moment, have a different repo for internally-developed plugins versus those provided by Artifactory, but even with just one internal repo, we would still want to use the gradle.properties values in the pluginRepositories block.


(Dimitar Dimitrov) #7

Please let me know if there is an issue for using Gradle properties in both pluginSettings {} and plugins {} sections. I’d vote for it.


(Waldemar Lammert) #8

Hello,

I can confirm, we’ve got the same problem in our company. Strange thing is - it works on our local machines, but is not working on the remote CI-Server (jenkins).


(Ryan Jaeb) #9

I would also like to have url and credentials read from gradle.properties. I’d like to use the pluginRepositories section exactly like @chefhoobajoob described in the original post.


(Patrick Armstrong) #10

I would also like to be able to use variables from gradle.properties in the pluginRepositories block. I’d like my plugins to come from artifactory and keep settings.gradle in source control, but ~/.gradle/gradle.properties has my artifactory credentials.


(Stefan Oehme) #11

This will be fixed in Gradle 3.0


(Adam Newman) #12

We have been using ~/.gradle/init.d/artifactory.gradle a file we created with contents like

allprojects {
  ext {
    local_artifactory_user = 'example.user'
    local_artifactory_password = 'ExampleArtifactoryApiKey'
  }
}

Then in build.gradle these are available as e.g. project.ext[‘local_artifactory_user’]. We also added a separate mechanism where it could come from this value or an environment variable based on a Jenkins secret credential set before the build. Each user has their own separate credentials and access rights, but no per-project setup work to do.

It is a little ugly, but it works every day on dozens of machines.


(Ron Dagostino) #13

Was this ever fixed? I’m seeing the same behavior with v3.4 – variables defined in ~/.gradle/gradle.properties are not available in settings.gradle.


(Mike Kobit) #14

Might make sense to open this as an issue on GitHub as this seems to affect multiple groups of people. It at least seems to sort-of work for a gradle.properties in the same project.

At least with 3.5-rc-1 right now:

settings.gradle

ratpackVersion=1.4.5

settings.gradle

pluginManagement {
  it.resolutionStrategy {
    it.eachPlugin {
      if (it.requested.id.id == 'io.ratpack.ratpack-java') {
        it.useVersion("${ratpackVersion}")
      }
    }
  }
}

That seems to work, but…

gradle.properties

ratpack.version=1.4.5

pluginManagement {
  it.resolutionStrategy {
    it.eachPlugin {
      if (it.requested.id.id == 'io.ratpack.ratpack-java') {
        it.useVersion("${ratpack.version}")
      }
    }
  }
}

This one fails (at least using gradle-script-kotlin:0.8.0) with:

Caused by: groovy.lang.MissingPropertyException: Could not get unknown property 'ratpack' for object of type org.gradle.plugin.management.internal.DefaultPluginResolveDetails.
        at org.gradle.internal.metaobject.AbstractDynamicObject.getMissingProperty(AbstractDynamicObject.java:88)
        at org.gradle.internal.metaobject.ConfigureDelegate.getProperty(ConfigureDelegate.java:134)

(Sebastian Schuberth) #15

For the record, I coincidentally filed an issue for this: https://github.com/gradle/gradle/issues/1697. Thanks for your comment over there!