DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Newsletter
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • Deploying a Kotlin App to Heroku
  • How to Build Your Own AI SRE From Scratch
  • Stop Preparing for Audits — Build the Pipeline That Audits Itself
  • Multi-Agent Software Engineering: Can AI Teams Build Production Systems?

Trending

  • Designing Frontend Applications for Failure, Not Just Success
  • Moving 900+ GB of Prometheus Without a Cutover Weekend
  • Treat Salesforce Configuration Like Code: Release Discipline in a Copado Pipeline
  • Why Vulnerability Management Fails Without Reliable Asset Data

Draft This article hasn't been published, so readers can't see it.

In moderation This article is waiting for review, so readers can't see it yet.

Deleted This article has been deleted, so readers can't see it.

Gradle Goodness: Checking Operating Systems in Build Scripts

Checking the OS in a build script is a common enough desire. You can do that with Gradle, but you shouldn't use the internal class that, on the face of it, would help.

By 
Hubert Klein Ikkink
·
Feb. 02, 17 · Tutorial
Post on X (opens in a new tab) Share on LinkedIn (opens in a new tab)
12.6K Views

Join the DZone community Save articles, join the discussion, and download Refcards and Trend Reports with a free account.

Join for free Already a member? Log in

Sometimes, we want to check which operating system is used in our build script. For example, we have tasks that need to run if the operating system is Windows and not for other operating systems. Gradle has an internal class that can help with that:

org.gradle.nativeplatform.platform.internal.DefaultOperatingSystem 

But we should not use this class in our build scripts. The class is used internally by Gradle and can change without warning. If we depend on this class and it changes, we break our build scripts. But we can use a class from Ant that is already in Gradle's class path:

org.apache.tools.ant.taskdefs.condition.Os

The class has several methods and constants to check the operating system name, version, and architecture. The values are based on the Java system properties os.name, os.version, and os.arch.

In the following example build script, we use import static to include the Os class, so we can directly invoke the methods and refer to the constants in the Os class. We add some tasks that have a condition check with onlyIf so the task only runs when the condition in the closure is true. The task osInfo simply shows values from the Os class:

// File: build.gradle
import static org.apache.tools.ant.taskdefs.condition.Os.*

task os {
    description 'Run all conditional os tasks'
}

// Create 3 tasks that simply print
// the task name that is executed
// if the build scripts runs on the
// recognized operating system.
[FAMILY_WINDOWS, FAMILY_UNIX, FAMILY_MAC].each { osName ->

    // Create task.
    tasks.create(osName) {
        description "Run when OS is ${osName}"

        // Add condition to check operating system.
        onlyIf { isFamily(osName) }

        doLast {
            println "Execute task '${it.name}'"
        }
    }

    // Add task as dependency for the os task.
    os.dependsOn osName
}


task osInfo {
    description 'Show information about the operating system'
    doLast {
        println "Family:       ${OS_NAME}"
        println "Version:      ${OS_VERSION}"
        println "Architecture: ${OS_ARCH}"
    }
}

Let's run the os and osInfo tasks on MacOS:

$ gradle os osInfo
mac
Execute task 'mac'
:unix
Execute task 'unix'
:windows SKIPPED
:os
:osInfo
Family:       mac os x
Version:      10.12.3
Architecture: x86_64

BUILD SUCCESSFUL

Total time: 0.697 secs

Written with Gradle 3.3.

operating system Build (game engine) Gradle

Published at DZone with permission of Hubert Klein Ikkink. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Deploying a Kotlin App to Heroku
  • How to Build Your Own AI SRE From Scratch
  • Stop Preparing for Audits — Build the Pipeline That Audits Itself
  • Multi-Agent Software Engineering: Can AI Teams Build Production Systems?

Partner Resources

×

Comments

Loading comments

The comments didn't load

Please try again in a moment.

Likes

Loading

The next likes didn't load. Please try again.

The likes didn't load

Please try again in a moment.

See who liked this

Log in or join DZone for free to see who liked this article.

Log in Join for free
  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook