Ennen kuin pääsemme ANT:iin, Maveniin tai Gradleen, meidän on ensin ymmärrettävä muutamia niihin liittyviä asioita.
Riippuvuus: Yleisesti ottaen riippuvuudella tarkoitetaan sitä, kun jokin asia vaatii jotain toista asiaa tullakseen itse suoritetuksi. Yksinkertaisesti sanottuna, ’A’ on riippuvainen ’B:stä’, jos ’A’ tarvitsee ’B:tä’ onnistuneeseen suoritukseensa. Ohjelmistomaailmassa riippuvuus on kaikki se, mitä sovelluksesi tarvitsee onnistuneeseen suoritukseensa. Se on periaatteessa mikä tahansa ulkoinen tukikirjasto, jota sovellus tarvitsee. esim. zuul, hystrix, lombok, jdbc, jne.
Alunperin meillä oli tapana hallita riippuvuuksia:
- lataamalla vaaditun kirjaston jar-tiedosto manuaalisesti internetistä ja lisäämällä se projektiin.
- kirjoittamalla komentosarja, joka lataa kirjaston automaattisesti ulkoisesta lähteestä verkon kautta.
Ongelmat, joita kohdataan ennen näitä työkaluja:
- Riippuvuuksien lisääminen lataamalla ne manuaalisesti internetistä on hyvin rasittava tehtävä.
- Skriptimme saattavat epäonnistua, jos ulkoisen lähteen URL-osoite muuttuu internetin kautta.
- Sovelluksessamme on hyvin vaikea tunnistaa ja hallita siirtyviä riippuvuuksia.
Riippuvuuksien hallinnan työkalu: Se ratkaisee ja hallitsee sovelluksen tarvitsemat riippuvuudet.
Rakennustyökalu: Se automatisoi suoritettavien sovellusten luomisen lähdekoodista. Rakentaminen sisältää koodin kääntämisen, linkittämisen ja pakkaamisen käyttökelpoiseen tai suoritettavaan muotoon. Rakentamisen automatisointiin kuuluu:
- Riippuvuuksien lataaminen
- Lähdekoodin kääntäminen binäärikoodiksi
- Tämän binäärikoodin paketoiminen
- Testien suorittaminen
- Tuotantojärjestelmiin levittäminen
Riippuvuuksienhallinta- ja rakentamistyökalut javassa:
Apache ANT (Another Neat Tool) on Apachen avoimen lähdekoodin projekti, joka julkaistiin vuonna 2000. Se on java-kirjasto, jota käytetään java-sovellusten rakentamisprosessien automatisointiin. Sitä voidaan käyttää myös muiden kuin Java-sovellusten rakentamiseen. Se noudattaa periaatetta ”Configuration over convention”. Antissa rakentamisprosessin eri vaiheita kutsutaan ”kohteiksi”. ANT:n rakennustiedostot on kirjoitettu XML-muodossa, ja niiden nimi on sopimuksen mukaan ”build.xml”. Se sisältää kolme elementtiä: projekti, kohde ja tehtävä. Jokainen build-tiedosto sisältää yhden projektin. Jokainen yksittäinen asia build.xml-tiedostossa on project-elementin alla. Projekti sisältää vähintään yhden kohteen (oletus). Kohde sisältää joukon tehtäviä ja määrittelee tietyn tilan rakentamisprosessissa. Tehtävä on koodinpätkä, joka voidaan suorittaa. Jokaiseen solmuun voi liittyä attribuutteja:
Attributes of Project:
- Name: Projektin nimi.
- Basedir: Projektin juurikansio ja se on valinnainen.
- Oletusarvo: Rakentamisen oletuskohde. Projektilla voi olla yksi tai useampi määrä kohteita. Sitä käytetään projektin oletuskohteen määrittämiseen.
Attributes of Target:
- Name: Kohteen nimi.
- Kuvaus: Kuvaus kohteesta.
- Depends: Luettelo kaikista pilkulla erotetuista kohteista, joista tämä kohde riippuu.
- If: Kohde suoritetaan, jos attribuutti on true.
- Unless: Kohde suoritetaan, jos attribuutti ei ole asetettu.
Build.xml-esimerkki:
<?xml version="1.0"?>
<project>
<target name="hello">
<echo>Hello, World</echo>
</target>
</project>
Add dependency in Ant + Ivy:
<dependency org="org.projectlombok" name="lombok" rev="1.18.10"/>
Antin tärkein etu on sen joustavuus. Ant ei pakota kehittäjälle mitään koodauskonventioita tai projektirakennetta. Näin ollen tämä tarkoittaa, että Ant vaatii kehittäjiä kirjoittamaan kaikki komennot itse, mikä johtaa joskus suuriin build-tiedostoihin ja on vaikea ylläpitää. Aluksi Antissa ei ollut sisäänrakennettua tukea riippuvuuksien hallinnalle. Myöhemmin se otti käyttöön Apache Ant -projektin aliprojektina kehitetyn Apache Ivyn riippuvuuksien hallintaa varten.
Apache Maven
Se on vuonna 2004 julkaistu riippuvuuksien hallinnan ja rakentamisen automatisoinnin työkalu. Se jatkaa XML:n käyttöä, mutta voittaa sen haitat noudattamalla periaatetta ”Convention over configuration”. Se luottaa konventioihin ja tarjoaa valmiita komentoja (tavoitteita). Sen konfigurointitiedosto, joka sisältää rakentamis- ja riippuvuuksienhallintaohjeita, on sopimuksen mukaan nimeltään ”pom.xml”, ja se on projektin juurikansiossa.
Maven-moottori ottaa syötteinä pom.xml:n ja projektin. Se lukee pom.xml-tiedoston ja lataa siinä mainitut riippuvuudet jar-tiedostoina paikalliseen arkistoon. Sitten se suorittaa elinkaaret, rakennusvaiheet ja lisäosat. Lopulta syntyy pakattu ja testattu artefakti.
pom.xml esimerkki:
Joitakin tärkeitä tunnisteita pom.xml-tiedostossa:
- groupId: Se edustaa organisaatiota, johon projekti kuuluu.
- artifactId: Se on projektin nimi.
- version: Se edustaa projektin versiota.
- packaging: Se edustaa projektin rakentamisen lopullista muotoa. esim. jar, war.
Add dependency in maven:
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.10</version>
</dependency>
Maven repository:
Repository on hakemisto, jossa kaikki pakatut jar-tiedostot ovat olemassa omien pom-tiedostojensa kanssa. Nämä pom-tiedostot sisältävät kyseisen projektin ulkoiset riippuvuudet. Tällä tavalla maven lataa projektisi riippuvuuksien riippuvuudet rekursiivisesti, kunnes kaikki tarvittavat riippuvuudet ovat paikallisessa arkistossasi. mavenissa on kolmenlaisia arkistoja:
- Paikallinen arkisto: Se on arkisto, joka on kehittäjän omalla koneella.
- Organisaatiotason/etä-arkisto: Se on organisaation sisällä oleva arkisto.
- Keskitetty arkisto: Se on maven-yhteisön luoma ja ylläpitämä internetissä sijaitseva arkisto.
Kun riippuvuus määritetään projektin pom.xml-tiedostossa, maven etsii sen paikallisesta arkistosta. Jos sitä ei löydy sieltä, se etsii sitä etä-/org-laajasta arkistosta. Jos sitä ei löydy sieltäkään, se etsii sitä keskusvarastosta.
Maven määrää tiukan projektirakenteen, kun taas Ant tarjoaa joustavuutta myös siinä. Sen tiukkojen konventioiden hintana on se, että se on paljon vähemmän joustava kuin Ant – tavoitteen muokkaaminen on hyvin vaikeaa.
Mavenin haitat:
- Riippuvuuksien hallinta ei käsittele hyvin ristiriitoja saman kirjaston eri versioiden välillä.
- Tavoitteiden räätälöinti on vaikeaa.
Gradle
Se on avoimen lähdekoodin riippuvuuksienhallinta- ja build-automaatiotyökalu, joka julkaistiin vuonna 2012. Se yhdistää Apache Antin ja Apache Mavenin hyvät puolet ja rakentaa niiden päälle ja käyttää XML:n sijaan toimialakohtaista kieltä (joka perustuu Groovyyn). Se otti joustavuuden Antista ja elinkaarensa Mavenista. Se noudattaa myös periaatetta ”Convention over configuration”. Se tukee Maven- ja Ivy-arkistoja riippuvuuksien hakemista varten. Sen konfigurointitiedoston nimi on ”build.gradle”, ja se on projektin juurikansiossa. Gradle antoi rakennusvaiheilleen nimen ”tasks”, toisin kuin Antin ”targets” tai Mavenin ”phases”. Google hyväksyi Gradlen Android OS:n oletuskehitystyökaluksi.
Gradle ei käytä XML:ää. Sen sijaan sillä oli oma Domain Specific Language, joka perustui Groovyyn (yksi JVM-kielistä). Tämän seurauksena Gradlen build-skriptit ovat yleensä paljon lyhyempiä ja selkeämpiä kuin Antille tai Mavenille kirjoitetut. Boilerplate-koodin määrä on paljon pienempi Gradlen kanssa.
Gradlen konfiguraatiot
- toteutus: Sitä käytetään sellaisten riippuvuuksien ilmoittamiseen, joita emme halua paljastaa kuluttajillemme kääntämisaikana.
- api: Sitä käytetään sellaisten riippuvuuksien ilmoittamiseen, jotka ovat osa API:tamme, eli sellaisten riippuvuuksien ilmoittamiseen, jotka haluamme nimenomaisesti paljastaa kuluttajillemme.
- compileOnly: Sen avulla voimme ilmoittaa riippuvuuksia, joiden pitäisi olla käytettävissä vain kääntämisaikana, mutta joita ei tarvita ajonaikana. Esimerkki käyttötapauksesta tälle määritykselle on Lombokin kaltainen annotaatiokäsittelijä, joka muokkaa tavukoodia kääntämisen aikana. Kääntämisen jälkeen sitä ei enää tarvita, joten riippuvuus ei ole käytettävissä ajonaikana.
- runtimeOnly: Se mahdollistaa sellaisten riippuvuuksien ilmoittamisen, joita ei tarvita kääntämisaikana, mutta jotka ovat käytettävissä ajonaikana. Esimerkki on SLF4J, jossa sisällytämme
slf4j-api
:nimplementation
-konfiguraatioon ja kyseisen API:n toteutuksen (kutenslf4j-log4j12
tailogback-classic
)runtimeOnly
-konfiguraatioon. - testImplementation: Samanlainen kuin
implementation
, muttatestImplementation
:llä ilmoitetut riippuvuudet ovat käytettävissä vain testien kääntämisen ja suorittamisen aikana. Voimme käyttää sitä ilmoittaessamme riippuvuuksia testauskehyksille, kuten JUnit tai Mockito, joita tarvitsemme vain testeissä ja joiden ei pitäisi olla saatavilla tuotantokoodissa. - testCompileOnly: Samanlainen kuin
compileOnly
, muttatestCompileOnly
:llä ilmoitetut riippuvuudet ovat käytettävissä vain testien kääntämisen aikana eikä ajonaikana. - testRuntimeOnly: Samanlainen kuin
runtimeOnly
, muttatestRuntimeOnly
:llatestRuntimeOnly
ilmoitetut riippuvuudet ovat käytettävissä vain testien ajonaikana eikä kääntämisen aikana.
Projektit ja tehtävät Gradlessa
Jokainen Gradle-rakennus koostuu yhdestä tai useammasta projektista. Jokainen projekti koostuu joukosta tehtäviä. Jokainen tehtävä edustaa yksittäistä työtä, jonka build suorittaa esim. generoi JavaDocin, julkaisee joitain arkistoja arkistoon jne.
build.gradle esimerkki
Gradle-repository:
Gradle:n ”aliaksia” käytetään Gradlessa silloin, kun lisätään Maven-arkistoja projektimme buildiin. Nämä aliakset ovat seuraavat:
- mavenCentral(): Tämä alias tarkoittaa riippuvuuksia, jotka haetaan Maven 2:n keskusvarastosta.
- jcenter(): Tämä alias tarkoittaa riippuvuuksia, jotka haetaan Bintrayn JCenter-Maven-arkistosta.
- mavenLocal(): Tämä alias tarkoittaa riippuvuuksia, jotka haetaan paikallisesta Maven-tietovarastosta.
Esimerkki: Lisää projektimme keskitetty Maven-tietovarasto, lisää seuraava koodinpätkä ’build.gradle’-tiedostoon:
repositories {
mavenCentral()
}
Add dependency in Gradle:
compile group: 'org.hibernate', name: 'hibernate-core', version: '3.6.7.Final'
Edut:
- Se käsittelee transitiiviset riippuvuudet melko hyvin. Jos projektissa on ristiriitainen transitiivinen riippuvuus, niin sen ratkaisemiseksi se valitsee uusimman version riippuvuudesta. Esimerkiksi riippuvuus ’A’ vaatii sisäisesti riippuvuutta ’C’, jonka versio on 2.0 ja riippuvuus ’B’ vaatii sisäisesti riippuvuutta ’C’, jonka versio on 3.0. Silloin Gradle käyttää riippuvuuden ’C’ uusinta versiota.
- Gradlen konfiguraatiotiedostot ovat kooltaan pienempiä ja siistimpiä, koska se käyttää XML:n sijasta Groovyyn perustuvaa toimialakohtaista kieltä.
- Gradle käyttää inkrementaalista rakentamiskonseptia ja välttää työtä seuraamalla tehtävien syötteitä ja tuotoksia ja suorittamalla vain sen, mikä on tarpeen, ja käsittelemällä vain muuttuneita tiedostoja, kun se on mahdollista, ja näin ollen se toimii nopeammin kuin maven.