Using Gradle

Spine uses Gradle as the project build system.

Gradle Configuration

1. Check out and open the project.
2. Sync Gradle. Wait for Maven repositories to be updated and indexes downloaded and built.
3. Build the project.

Use Gradle wrapper instead of local Gradle distribution. To do so, use gradlew clean instead of gradle clean and so on.

Note: Before configuring Gradle, make sure you have granted execution rights to Gradle wrapper on Unix-based systems using the chmod +x ./gradlew command.

Not using snapshot versions

By default, Gradle build does not support snapshots. Although it is possible to make Gradle work with them, it turned out to be troublesome.

That's why the framework development is based on interim release versions done using patch version component (e.g. 1.5.25) and official release versions where the last (patch) component is zero (e.g. 1.5.0). Please see Versioning for details.

Gradle code style

No semicolons

Do not use semicolons at the end of a line (they can be used in loops, though).

Use return keyword

Always use return keyword to make the code more readable and less error-prone.

Use parentheses

Use parentheses in top-level expressions, for example, println("Hello") instead of println "Hello".
This should be applied to regular methods in plugin classes. Parentheses can be omitted in the build.gradle files.

No public keyword

By default, Groovy considers classes and methods public. Do not use any keyword to be more concise.

No Java-style getters and setters definition

Instead of:

class Person {
    private String name
    String getName() { return name }
    void setName(String name) { this.name = name }
}

Write:

class Person {
    String name
}

As you can see, a free standing 'field' without modifier visibility actually makes the Groovy compiler to generate a private field, getter and setter for you.

Use == instead of equals()

Java’s == is actually Groovy’s is() method, and Groovy’s == is a clever equals().
To compare the references of objects, instead of ==, you should use a.is(b).
To do the equals() comparison, you should prefer Groovy’s ==, as it also takes care of avoiding NullPointerException, independently of whether the left or right is null or not.
Instead of:

a != null && a.equals(b)

Do:

a == b

Use GString instead of String on construction

Because the code reads better and it is more convenient to type:

"my string $var and $other"

instead of:

"my sting " + var + " and " + other.

Important

GString is not String.

For example, putting GStrings to Map<String, Value> leads to bugs, because the map will return null if try to get something by String.

So, use the exact type to avoid such bugs (especially for map keys). Since it is convenient to use Strings in other places, we should pay attention to these types.

Project-wide properties

Define in the ext block. Use lowerCamelCase as in Gradle documentation and samples.