streamalism.org

1. Oversikt

Kildesett gir oss en kraftig måte å strukturere kildekoden i Gradle-prosjektene våre.

I denne raske opplæringen skal vi se hvordan du bruker dem.

2. Standard kildesett

Før vi hopper inn i standardinnstillingene, la oss først forklare hva kildesett er. Som navnet tilsier, kildesett representerer en logisk gruppering av kildefiler.

Vi vil dekke konfigurasjonen av Java-prosjekter, men konseptene gjelder også for andre Gradle-prosjekttyper.

2.1. Standard prosjektoppsett

La oss starte med en enkel prosjektstruktur:

kildesett ├── src │ └── hoved │ ├── java │ │ ├── SourceSetsMain.java │ │ └── SourceSetsObject.java │ └── test │ └── SourceSetsTest.java └── bygge. gradering 

La oss nå ta en titt på build.gradle:

bruk plugin: "java" description = "Kilde Setter eksempel" test {testLogging {events "gått", "hoppet over", "mislyktes"}} avhengigheter {implementering ('org.apache.httpcomponents: httpclient: 4.5.12') testImplementation ('junit: junit: 4.12')}

Java-pluginet forutsetter src / main / java og src / test / java som standard kildekataloger.

La oss lage en enkel verktøyoppgave:

oppgave printSourceSetInformation () {doLast {sourceSets.each {srcSet -> println "[" + srcSet.name + "]" print "-> Kildekataloger:" + srcSet.allJava.srcDirs + "\ n" print "-> Output kataloger: "+ srcSet.output.classesDirs.files +" \ n "println" "}}}

Vi skriver ut bare noen få kildesettegenskaper her. Vi kan alltid sjekke hele JavaDoc for mer informasjon.

La oss kjøre det og se hva vi får:

$ ./gradlew printSourceSetInformation> Oppgave: kildesett: printSourceSetInformation [main] -> Kildekataloger: [... / source-sets / src / main / java] -> Output kataloger: [... / source- sett / build / klasser / java / main] [test] -> Kildekataloger: [... / kildesett / src / test / java] -> Utgangskataloger: [... / kildesett / bygg / klasser / java / test] 

Legge merke til vi har to standard kildesett: hoved- og test.

2.2. Standardkonfigurasjoner

Java-pluginet oppretter også automatisk noen standard Gradle-konfigurasjoner for oss.

De følger en spesiell navnekonvensjon: .

Vi bruker dem til å erklære avhengighet i build.gradle:

avhengigheter {implementering ('org.apache.httpcomponents: httpclient: 4.5.12') testImplementation ('junit: junit: 4.12')}

Legg merke til at vi spesifiserer gjennomføring i stedet for mainImplementation. Dette er et unntak fra navnekonvensjonen.

Som standard, testImplementering konfigurasjonen utvides gjennomføring og arver alle sine avhengigheter og utganger.

La oss forbedre hjelperoppgaven vår og se hva dette handler om:

oppgave printSourceSetInformation () {doLast {sourceSets.each {srcSet -> println "[" + srcSet.name + "]" print "-> Kildekataloger:" + srcSet.allJava.srcDirs + "\ n" print "-> Output kataloger: "+ srcSet.output.classesDirs.files +" \ n "print" -> Kompilere classpath: \ n "srcSet.compileClasspath.files.each {print" "+ it.path +" \ n "} println" "} }}

La oss ta en titt på utgangen:

[hoved] // samme utgang som før -> Kompiler klassesti: ... / httpclient-4.5.12.jar ... / httpcore-4.4.13.jar ... / commons-logging-1.2.jar .. ./commons-codec-1.11.jar [test] // samme utgang som før -> Kompiler klassesti: ... / kildesett / bygg / klasser / java / hoved ... / kildesett / bygg / ressurser / main ... / httpclient-4.5.12.jar ... / junit-4.12.jar ... / httpcore-4.4.13.jar ... / commons-logging-1.2.jar ... / commons- codec-1.11.jar ... / hamcrest-core-1.3.jar

De test kildesettet inneholder utgangene til hoved- i kompileringsveien og inkluderer også dens avhengigheter.

La oss deretter lage vår enhetstest:

offentlig klasse SourceSetsTest {@Test offentlig ugyldig når Run_ThenSuccess () {SourceSetsObject underTest = ny SourceSetsObject ("lorem", "ipsum"); assertThat (underTest.getUser (), er ("lorem")); assertThat (underTest.getPassword (), er ("ipsum")); }}

Her tester vi en enkel POJO som lagrer to verdier. Vi kan bruke den direkte fordi de hoved- utgangene er i vårt test klassesti.

La oss kjøre dette fra Gradle:

./gradlew clean test> Oppgave: kildesett: test com.baeldung.test.SourceSetsTest> whenRunThenSuccess PASSED 

3. Tilpassede kildesett

Så langt har vi sett noen fornuftige standarder. I praksis trenger vi imidlertid ofte tilpassede kildesett, spesielt for integrasjonstester.

Det er fordi vi kanskje bare vil ha spesifikke testbiblioteker på klassestien til integrasjonen. Vi vil kanskje også utføre dem uavhengig av enhetstester.

3.1. Definere tilpassede kildesett

La oss lage en egen kildekatalog for våre integrasjonstester:

kildesett ├── src │ └── hoved │ ├── java │ │ ├── SourceSetsMain.java │ │ └── SourceSetsObject.java │ ├── test │ │ └── SourceSetsTest.java │ └── itest │ └── SourceSetsITest.java └── build.gradle 

Neste, la oss konfigurer det i vår build.gradle bruker sourceSets konstruere:

sourceSets {itest {java {}}} avhengigheter {implementering ('org.apache.httpcomponents: httpclient: 4.5.12') testImplementation ('junit: junit: 4.12')} // andre erklæringer utelatt 

Legg merke til at vi ikke spesifiserte noen tilpasset katalog. Det er fordi mappen vår samsvarer med navnet på det nye kildesettet (itest).

Vi kan tilpasse hvilke kataloger som følger med srcDirs eiendom:

sourceSets {itest {java {srcDirs ("src / itest")}}}

Husker du hjelperoppgaven vår fra begynnelsen? La oss kjøre på nytt og se hva den skriver ut:

$ ./gradlew printSourceSetInformation> Oppgave: kildesett: printSourceSetInformation [itest] -> Kildekataloger: [... / source-sets / src / itest / java] -> Output kataloger: [... / source- sett / bygg / klasser / java / itest] -> Kompilér klassebane: ... / kildesett / bygg / klasser / java / hoved ... / kildesett / bygg / ressurser / hoved [hoved] // samme utgang som før [test] // samme utgang som før

3.2. Tilordne kildesett spesifikke avhengigheter

Husker du standardkonfigurasjoner? Vi får nå noen konfigurasjoner for itest kildesett også.

La oss bruke itestImplementation for å tilordne en ny avhengighet:

avhengigheter {implementering ('org.apache.httpcomponents: httpclient: 4.5.12') testImplementation ('junit: junit: 4.12') itestImplementation ('com.google.guava: guava: 29.0-jre')}

Denne gjelder bare integrasjonstester.

La oss endre vår forrige test og legge den til som en integrasjonstest:

public class SourceSetsItest {@Test public void givenImmutableList_whenRun_ThenSuccess () {SourceSetsObject underTest = new SourceSetsObject ("lorem", "ipsum"); List someStrings = ImmutableList.of ("Baeldung", "is", "cool"); assertThat (underTest.getUser (), er ("lorem")); assertThat (underTest.getPassword (), er ("ipsum")); assertThat (someStrings.size (), er (3)); }}

Å være i stand til å kjøre den, vi må definere en tilpasset testoppgave som bruker de kompilerte utgangene:

// kilde setter erklæringer // avhengighetserklæringer oppgave itest (type: Test) {description = "Kjør integrasjonstester" group = "verification" testClassesDirs = sourceSets.itest.output.classesDirs classpath = sourceSets.itest.runtimeClasspath}

Disse erklæringene blir evaluert i løpet av konfigurasjonsfasen. Som et resultat, deres ordre er viktig.

For eksempel kan vi ikke referere til itest kilde satt i oppgaveorganet før dette blir erklært.

La oss se hva som skjer hvis vi kjører testen:

$ ./gradlew clean itest // noen kompileringsproblemer FEIL: Bygg mislyktes med unntak. * Hva gikk galt: Utførelsen mislyktes for oppgaven ': source-sets: compileItestJava'. > Kompilering mislyktes; se kompilatorens feilutdata for detaljer.

I motsetning til forrige løp får vi en kompileringsfeil denne gangen. Så hva skjedde?

Dette nye kildesettet skaper en uavhengig konfigurasjon.

Med andre ord, itestImplementation arver ikke JUnit avhengighet, og det får heller ikke utgangene fra hoved-.

La oss fikse dette i vår Gradle-konfigurasjon:

sourceSets {itest {compileClasspath + = sourceSets.main.output runtimeClasspath + = sourceSets.main.output java {}}} // avhengighetserklæringskonfigurasjon {itestImplementation.extendsFrom (testImplementation) itestRuntimeOnly.extendsFrom (testRuntimeOnly)}

La oss kjøre om vår integrasjonstest på nytt:

$ ./gradlew clean itest> Task: source-sets: itest com.baeldung.itest.SourceSetsItest> givenImmutableList_whenRun_ThenSuccess PASSED

Testen består.

3.3. Formørkelse IDE-håndtering

Vi har så langt sett hvordan vi kan jobbe med kildesett direkte med Gradle. Imidlertid bruker vi mest en gang en IDE (som Eclipse).

Når vi importerer prosjektet, får vi noen kompileringsproblemer:

Men hvis vi kjører integrasjonstesten fra Gradle, får vi ingen feil:

$ ./gradlew clean itest> Task: source-sets: itest com.baeldung.itest.SourceSetsItest> givenImmutableList_whenRun_ThenSuccess PASSED

Så hva skjedde? I dette tilfellet guava avhengighet tilhører itestImplementation.

Dessverre, plugin-programmet Eclipse Buildship Gradle takler ikke disse tilpassede konfigurasjonene veldig bra.

La oss fikse dette i vår build.gradle:

bruk plugin: "eclipse" // tidligere erklæringer eclipse {classpath {plusConfigurations + = [configurations.itestCompileClasspath]}} 

La oss forklare hva vi gjorde her. Vi la til konfigurasjonen vår til Eclipse classpath.

Hvis vi oppdaterer prosjektet, er problemene med kompilering borte.

Derimot, det er en ulempe med denne tilnærmingen: IDE skiller ikke mellom konfigurasjoner.

Dette betyr vi kan enkelt importere guava i vår test kilder (som vi spesielt ønsket å unngå).

4. Konklusjon

I denne opplæringen dekket vi det grunnleggende om Gradle-kildesett.

Så forklarte vi hvordan tilpassede kildesett fungerer og hvordan du bruker dem i formørkelse.

Som vanlig kan vi finne den fullstendige kildekoden på GitHub.