Steuern der Laufzeitabhängigkeiten von Buildle mit dem Build-Parameter

Question

Ich benutze Gradle und sein ShadowJar-Plugin, um ein Fat-Jar für meine Anwendung zu erstellen, die in einem von zwei Kontexten bereitgestellt wird.

In einem Kontext stellt die Umgebung die Abhängigkeiten A, B und C (und alle ihre transitiven Abhängigkeiten) bereit, und diese Klassen sollten nicht Teil meines Fat Jars sein.

In dem anderen Kontext stellt die Umgebung nur die Abhängigkeiten A und B bereit und ich muss sicherstellen, dass C und alle seine transitiven Abhängigkeiten in meinem fetten Jar gebündelt sind.

Wie kann ich dieses Verhalten in meiner Gradle-Build-Datei definieren? Ich denke, der beste Weg wäre, die Eigenschaft runtime.exclude irgendwie basierend auf einem Build-Ziel oder Kommandozeilenparameter anzupassen.

Answer 1

Also ich denke, Sie suchen nach zwei Konfigurationen.

apply plugin: 'groovy' 

repositories { 
    jcenter() 
} 

dependencies { 
    compile localGroovy() 
    compile 'org.slf4j:slf4j-api:1.7.21' 
    compileOnly group: 'com.google.guava', name: 'guava', version: '20.0' 
    testCompile 'junit:junit:4.12' 
} 

task fatJar(type: Jar) { 
    from sourceSets.main.output, configurations.compile 
    baseName = "$project.name-fat" 
} 

jar.dependsOn fatJar 

Jetzt können wir ein Glas für jeden Kontext schaffen wir interessiert sind, in

$ ./gradlew clean build 
Configuration on demand is an incubating feature. 
:clean 
:compileJava UP-TO-DATE 
:compileGroovy 
:processResources UP-TO-DATE 
:classes 
:fatJar 
:jar 
:assemble 
:compileTestJava UP-TO-DATE 
:compileTestGroovy UP-TO-DATE 
:processTestResources UP-TO-DATE 
:testClasses UP-TO-DATE 
:test UP-TO-DATE 
:check UP-TO-DATE 
:build 

BUILD SUCCESSFUL 

Total time: 4.997 secs 

auf den Einsatz lässt nun überprüfen, ob wir ein fettes Glas

$ unzip build/libs/q40727142-fat.jar -d build/libs/included 
Archive: build/libs/q40727142-fat.jar 
    creating: build/libs/included/META-INF/ 
    inflating: build/libs/included/META-INF/MANIFEST.MF 
    creating: build/libs/included/com/ 
    creating: build/libs/included/com/jbirdvegas/ 
    creating: build/libs/included/com/jbirdvegas/q40727142/ 
    inflating: build/libs/included/com/jbirdvegas/q40727142/Hello.class 
    inflating: build/libs/included/groovy-all-2.4.7.jar 
    inflating: build/libs/included/slf4j-api-1.7.21.jar 

Und lässt überprüfen die Original Konfiguration hat nicht unsere Gläser, wie sie voraussichtlich zur Verfügung gestellt werden.

$ unzip build/libs/q40727142.jar -d build/libs/notIncluded 
Archive: build/libs/q40727142.jar 
    creating: build/libs/notIncluded/META-INF/ 
    inflating: build/libs/notIncluded/META-INF/MANIFEST.MF 
    creating: build/libs/notIncluded/com/ 
    creating: build/libs/notIncluded/com/jbirdvegas/ 
    creating: build/libs/notIncluded/com/jbirdvegas/q40727142/ 
    inflating: build/libs/notIncluded/com/jbirdvegas/q40727142/Hello.class 

Answer 2

ich mit einem Build-Datei ging, die wie folgt aussieht:

subprojects { 
    apply plugin: "java" 
    apply plugin: "scala" 
    version = "1.0-SNAPSHOT" 
    group = "com.example.projects" 
    ext.deployEnv = "Env1" 

    if (project.hasProperty("deployEnv")) { 
     ext.deployEnv= project.property("deployEnv") 
    } 
} 

project(":myproject") { 
    configurations { 
     runtime.exclude group: 'A' 
     runtime.exclude group: 'B' 
    } 

    if (ext.deployEnv == 'Env0') { 
     configurations { 
      runtime.exclude group:'C' 
     } 
    } 
} 

Es tut, was ich will, mit minimalen Änderungen an der Build-Datei.