Access constant from Groovy class in Gradle buildfile

Help/Discuss
#1

I implement a Gradle plugin - defining some required constants in a Groovy class
like

class MyConstants { public final static String blurbId = "xyz" }

Now I want to access this constant “blurbId” from Gradle build…
Tried JavaExec, but in vain, as I have no main method to call…
How can I assign this Groovy constant to a Gradle variable (in ext-block?)

I tried JavaExec, but in vain.

thx

#2

Hey Gernot,

not sure I understand you correctly, but you have packaged a gradle plugin and trying now to referece a constant within the build.gradle file?

you should be able to reference it just by the full qualified class name and the const ID:

task printIt << {
     println acme.MyConstants.blurbId
}

cheers,
René

#3

thx René,
tried similar way (where “org.aim42…” is the fully qualified name of the class I need to access:

ext {
    javaVersion = System.getProperty("java.version")
    currentDate = new Date().format("d. MMM yyyy")
    versionId = org.aim42.htmlsanitycheck.ProductVersion.versionId
}

and got:

Could not find property 'org' on root project 'htmlSanityCheck'.

The class I’m trying to access is part of the project that will be published
as Gradle plugin. Classpath issue?

#4

Gernot, you are right about the classpath. You still need to tell Gradle about the classpath in the buildscript even if you don’t have an apply plugin.

buildscript {
  dependencies {
   // the classic way
     classpath 'group:module:version'

  // OR you can do
    classpath fileTree ( dir: '/path/to/Jars' include:'*.jar' )
}
#5

Ah now I see what you’re trying. ProductVersion is part of your project you’re building which is a gradle plugin and not part of a gradle plugin you use for building your project.

This is currently not out of the box supported, because the classes of the project itself are not part of the build classpath. You have different options here I guess

  1. use regex to get the versionId out of your ProductVersion class
  2. reverse the way the version is handled. you can declare the version in your build script and then prepocess your ProductVersion java file to get this version information backed into this file.
  3. alternatively use a method in ProductVersion to resolve the version from a property file instead of having a field for this. From the user perspective this would look the same as your current user api as you can take advantage from groovy’s property syntax.

personally I would go with option3. A solution could look like this:

   //your ProductVersion class
class ProductVersion {
    public static String getVersionId() {
        try{
            final URL resource = ProductVersion.class.getClassLoader().getResource("htmlsanitycheckversion.properties");
            Properties props = new Properties()
            props.load(resource.openConnection().inputStream)
            return props.getProperty("version");
        } catch (IOException E) {
        }
        return "[unknown]";
    }
}

You would need an additional properties file where you store the version information:

# a file src/main/resources/htmlsanitycheckversion.properties
version=@version@

Now you just need to ensure this version information is updated during the build:

// in your build.gradle file
processResources {
    inputs.property "version", project.version
    filter(org.apache.tools.ant.filters.ReplaceTokens, tokens: [version: project.version])
}

Now you still have the contract of ProductVersion.versionId, but the version information is owned by the build process, which is imo the better place for this information.

cheers,
René

1 Like
#6

René, thanx for your extensive answer…

Great idea, the ProductVersion class works fine…

just to add a bit:

I have to define the version-variable within build.gradle:

version=“0.2.0-SNAPSHOT”

#7

well you can have the version information declared in your build.gradle
file or in a gradle.properties file. it is up to you. people tend to put
this into the gradle.properties file (next to your build.gradle file)
these days as it is easier to maintain (and to automate)

cheers,
René

1 Like