Equivalent to product flavors in non-Android Gradl

Question

I'm creating a desktop Java app and would like to create two versions: free and paid. The difference is mainly in which resource files are included (at a future date, it may involve different code as well, but not right now).

I've read about Android build variants allowing for just this sort of thing through "product flavors". However, this seems to be a feature unique to the android plugin, which is obviously not available on the desktop.

Is there an equivalent to these product flavors that does not depend on the androidplugin?

If it helps, my end goal is to find a way that I can run the Gradle build task and output two different versions of the app, which is my understanding of what the Android build variants accomplishes.

Answer 1

Sure you can use sourceSets and customize the Jar tasks to accomplish the same effect.

group 'com.jbirdvegas.example'
version '1.0-SNAPSHOT'

repositories {
    jcenter()
}

// adding the java plugin add the `jar` task to the build task graph
apply plugin: 'java'

compileJava {
    sourceCompatibility = JavaVersion.VERSION_1_8
    targetCompatibility = JavaVersion.VERSION_1_8
}

/**
 * SourceSets allows different builds to have their own
 * code.  If main and flavorOne contain com.foo.Bar then
 * the `flavorOne` jar will contain the file specified by
 * the `flavorOne` source set files.
 */
sourceSets {
    main {
        // you could also do per sourceSet resources if needed
        java.srcDir 'src/main/java'
    }
    flavorOne {
        java.srcDir 'src/flavorOne/java'
    }
    flavorTwo {
        java.srcDir 'src/flavorTwo/java'
    }
}

/**
 * Creates the first flavor's jar when the Java plugin's `Jar`
 * task is called.  Since the `jar` task depends on `flavorOne` task
 * this task will run before the generic `jar` task which produces
 * the base .jar artifact.
 */
task flavorOne(type: Jar) {
    from sourceSets.flavorOne.output
    classifier = 'flavorOneJar'
    manifest {
        attributes "Main-Class": "de.jeha.photo.mosaic.cli.Main"
    }
}

/**
 * Creates the second flavor's jar when the Java plugin's `Jar`
 * task is called.  `flavorTwo` can run before `flavorOne` because
 * both must just run before the `jar` task (base artifact)
 */
task flavorTwo(type: Jar) {
    from sourceSets.flavorTwo.output
    classifier = 'flavorTwoJar'
    manifest {
        attributes "Main-Class": "de.jeha.photo.mosaic.cli.Main"
    }
}

// be sure to build all flavors whenever the `jar` task runs
jar.dependsOn flavorOne, flavorTwo

dependencies {
    // you can declare different dependencies per sourceSets
    flavorOneCompile 'com.google.code.gson:gson:2.5'
    flavorTwoCompile 'com.something:else:1.0'
    compile 'commons-io:commons-io:2.4'
    testCompile group: 'junit', name: 'junit', version: '4.11'
}

/**
 * if you want to have specific control over the main jar's
 * build then you could configure the main jar as needed.
 * This is the equivalent of the `flavorBlah` tasks except
 * this task was added for us by the `java` plugin.  Changes
 * here will only affect the main jar built from `sourceSet.main`
 *
 * Think of this as the default where other `productFlavors` are
 * completely divorced from this jar's configuration.
 */
jar {
    manifest {
        attributes "Main-Class": "de.jeha.photo.mosaic.cli.Main"
    }
}

Then we can see the different builds. Our flavors and the main source set jar.

$ ls -l build/libs/
-rw-r--r--  1 jbirdvegas  63209268   1.3K Jan  6 08:58 my-sweet-jar-1.0-SNAPSHOT-flavorOneJar.jar
-rw-r--r--  1 jbirdvegas  63209268   302B Jan  6 08:58 my-sweet-jar-1.0-SNAPSHOT-flavorTwoJar.jar
-rw-r--r--  1 jbirdvegas  63209268    18K Jan  6 08:58 my-sweet-jar-1.0-SNAPSHOT.jar