Projekta veidošana ir sarežģīts bizness. Sakarā ar desmitiem uzdevumu, kas nepieciešami, pārveidojot failu hodge-podge par darba programmu, burtiski ir simtiem rīku, kas visu dara, sākot no avota koda ģenerēšanas, līdz kompilēšanai, testēšanai, izplatīšanai un rīta kafijas pagatavošanai (ja tu tādu atrodi, dārgais lasītāj, dari man zināmu). Daudzas no šīm programmām lieliski darbojas tajā, ko viņi dara. Diemžēl tiem, kas pārvalda liela apjoma būvniecības sistēmas iztikai, reti ir daudz kopības; katrai programmai nepieciešama sava atšķirīgā instalācija un ezotēriskā konfigurācija. Tas ir kļuvis par neizbēgamu mūsu dzīves faktu, ka lielākā daļa būvēšanas sistēmu tiek veidotas pēc pasūtījuma, līmējot šos rīkus ar vairākiem pašmāju skriptiem (jā, skudru skripti skaitās).
Vairāk nekā cits veidošanas rīks, Maven ir būvējums ietvaros. Tas tīri atdala kodu no konfigurācijas failiem, dokumentācijas un atkarībām. Maven ir pārsteidzoši elastīgs, ļaujot lietotājiem konfigurēt lielāko daļu sava koda aspektu, kā arī kontrolēt spraudņu darbību, individuālos mērķus un pat pašu būvēšanas dzīves ciklu. Maven ir faktiskā struktūra, un šajās sienās dzīvo jūsu projekts; tā vēlas būt uzņemoša saimniece.
Bet problēma joprojām pastāv: tūkstošiem pielāgotu veidošanas skriptu darba pārvaldīšana vienā sistēmā ir grūta, un, lai to izdarītu pareizi, ir nepieciešama daudz informācijas. Par laimi Maven 2 komanda ir bijusi diezgan veiksmīga. Mācoties no Maven 1 kļūdām, neskaitāmiem lietotāju pieprasījumiem, pielāgošanas un atjaunināšanas, Maven 2 ir jaudīgāks nekā jebkad agrāk. Diemžēl ar lielu jaudu nāk lieliska konfigurācija. Lai Maven 2 artefakti būtu viegli pārnēsājamas vienības, šī sarežģītā konfigurācija ietilpst vienā failā. Ievadiet Maven POM.
Kas ir POM?
POM nozīmē projekta objekta modeli. Tas ir Maven projekta XML attēlojums, kas atrodas failā ar nosaukumu pom.xml. Mavena ļaužu klātbūtnē runāšana par projektu ir filozofiskā nozīmē, kas pārsniedz vienkāršu failu kolekciju ar kodu. Projektā ir konfigurācijas faili, kā arī iesaistītie izstrādātāji un spēlētās lomas, defektu izsekošanas sistēma, organizācija un licences, URL, kurā dzīvo projekts, projekta atkarības un visi pārējie sīkie elementi, kas tiek izmantoti koda piešķiršanai. dzīve. Projekts ir vienas pieturas aģentūra visām ar to saistītajām lietām. Faktiski Maven pasaulē projektam vispār nav jābūt kodam, tikai pom.xml. Ar pāris šāda veida projektiem mēs sastapsimies vēlāk rakstā.
Ātrs strukturāls pārskats
POM ir liels un sarežģīts, tāpēc tā sadalīšana gabalos atvieglo gremošanu. Šīs diskusijas vajadzībām šie gabali tiek pārgrupēti četrās loģiskās vienībās, kā parādīts 1. attēlā: POM attiecības, projekta informācija, būvēšanas iestatījumi un veidošanas vide. Mēs sāksim apspriest POM attiecības.
Zemāk ir saraksts ar elementiem, kas atrodas tieši zem POM projekta elementa. Ievērojiet to modelVersion satur 4.0.0. Šī pašlaik ir vienīgā Maven 2 atbalstītā POM versija, un tā vienmēr ir nepieciešama. Maven 4.0.0 XML shēmas definīcija atrodas vietnē //maven.apache.org/maven-v4_0_0.xsd. Tās augstākā līmeņa elementi ir šādi:
4.0.0
... ... ... ... ... ... ...
... ... ... ... ... ... ... ...
... ... ... ...
... ... ... ...
... ... ... ... ...
POM attiecības
Mūsu pirmā darba kārtība ir izpētīt projektu attiecības, kas attēlotas 2. attēlā kā diagrammas augšējais kreisais stūris 1. attēlā.
Projektiem kaut kādā veidā jābūt savstarpēji saistītiem. Kopš pirmo montētāju izveidošanas programmatūras projekti ir bijuši atkarīgi; Maven Java projektiem ir ieviesis vairāk līdz šim neizmantotu attiecību formu. Šīs attiecības ir Mavenas koordinātas, uz koordinātām balstītas atkarības, projekta mantošana un apkopošana.
Koordinātas
Katrā Maven projektā ir savs unikālais identifikators, kas tiek dēvēts par projektu koordinātas, kas darbojas kā artefakta adrese, piešķirot tai unikālu vietu Maven visumā. Ja projekti nevarētu savstarpēji sazināties, koordinātas nebūtu vajadzīgas. Tas ir, ja Visumam būtu tikai viena māja, kāpēc tam būtu nepieciešama adrese, piemēram, 315 Cherrywood Lane?
Tālāk redzamais kods ir minimālais POM, ko atļaus Maven 2—, , un ir visi obligātie lauki. Viņi darbojas kā vektors Maven telpā ar elementiem grupētājs, identifikators un laika zīmogs.
4.0.0org.codehaus.mojoa1Mavenas pasaulē šie trīs galvenie elementi (Mavenas trīsvienība - lūk, tā godība!) Veido POM koordinātas. Koordinātas attēlo 3. attēls.
Varbūt šis POM pats par sevi nav tik iespaidīgs. Kļust labāk.
Atkarības
Viens no visspēcīgākajiem Maven aspektiem ir tā, kā rīkoties ar projektu atkarībām, un Maven 2, kas ietver transitīvas atkarības. 4. attēlā parādīts, kā mēs tos attēlosim grafiski.
Atkarības pārvaldībai ir senas tradīcijas, ka tas ir sarežģīts haoss jebkuram citam, izņemot visniecīgākajiem projektiem. "Džarmagedons" ātri iestājas, kad atkarības koks kļūst milzīgs, sarežģīts un apkaunojošs arhitektiem, kurus nicina jaunie absolventi, kuri "pilnīgi to varēja izdarīt labāk". Seko "Jar Hell", kur atkarības no vienas sistēmas versijas nav gluži tās pašas versijas, kuras tiek izmantotas attīstībai; tiem ir vai nu nepareiza versija, vai arī konfliktējošas versijas starp līdzīgi nosauktajiem JAR. Tādējādi lietas sāk lauzt un precīzi noteikt, kāpēc izrādās grūti. Maven atrisina abas šīs problēmas ar kopēju vietējo repozitoriju, no kura var izveidot saiti ar pareizajiem projektiem, versijām un visiem.
Mantojums
Viena no iezīmēm, ko Maven 2 nes no Maven 1 dienām, ir projekta mantošana, kā parādīts 5. attēlā. Veidošanas sistēmās, piemēram, Ant, mantošanu noteikti var simulēt, taču Maven ir spēris papildu soli, lai projekta mantojums būtu nepārprotams. projekta objekta modeli.
Šis kods definē vecāku POM Maven 2:
4.0.0org.codehaus.mojob2pomŠis vecāks izskatās līdzīgs mūsu pirmajam POM, ar nelielu atšķirību. Ievērojiet, ka esam iestatījuši iepakojums ierakstiet kā pom, kas ir nepieciešams gan vecāku, gan apkopotāju projektiem (mēs to vairāk aplūkosim iepakojums sadaļā "Veidošanas iestatījumi"). Ja mēs vēlamies izmantot iepriekš minēto projektu kā vecāku, mēs varam mainīt projektu org.codehaus.mojo: a POM būt:
4.0.0org.codehaus.mojob2aIr svarīgi atzīmēt, ka visi POM tiek mantoti no vecākiem neatkarīgi no tā, vai tie ir skaidri definēti vai nav. Šī pamata POM ir pazīstama kā “super POM”, un tajā ir vērtības, kas pēc noklusējuma tiek pārmantotas. Vienkāršs veids, kā apskatīt super POM noklusējuma konfigurācijas, ir izveidot vienkāršu pom.xml ar neko citu modelVersion, groupId, artefactId, un versijaun palaižot komandu mvn help: efektīvs-pom.
Papildus vērtību iestatīšanai mantošanai vecākiem ir arī tiesības izveidot noklusējuma konfigurācijas saviem bērniem, faktiski neuzliekot viņiem vērtības. Atkarības pārvaldība ir īpaši spēcīgs instruments atkarību kopas konfigurēšanai, izmantojot kopēju atrašanās vietu (POM vecāku). The atkarībaVadība elementu sintakse ir līdzīga atkarības sadaļas sintaksei. Tomēr tas ļauj bērniem mantot atkarības iestatījumus, bet ne pašu atkarību. Pievienojot atkarību ar atkarībaVadība elements faktiski nepievieno atkarību no POM, kā arī nepievieno atkarību no bērniem; tā izveido noklusējuma konfigurāciju jebkurai atkarībai, kuru bērns var izvēlēties pievienot savā atkarības sadaļā. Iestatījumi līdz atkarībaVadība attiecas arī uz pašreizējo POM atkarības konfigurāciju (lai gan atkarības elementa iekšpusē ignorētās konfigurācijas vienmēr ir prioritāras).
Apkopošana
Projekts ar moduļiem ir pazīstams kā daudzmoduļu projekts. Moduļi ir projekti, kurus POM uzskaita un izpilda kā kopu. Vairāku moduļu projekti zina savus moduļus, bet otrādi ne vienmēr ir taisnība, kā parādīts 6. attēlā.
Pieņemot, ka vecāku POM atrodas vecāka direktorijā, kur projekta POM a un ka projekts a arī dzīvo tā paša nosaukuma direktorijā, mēs varam mainīt vecāku POM b lai apkopotu bērnu a pievienojot to kā moduli:
4.0.0org.codehaus.mojob2pomaTagad, ja mēs skrējām mvn sastādīt bāzes direktorijā redzētu, ka būvēšana sākas ar:
[INFO] Notiek projektu meklēšana ... [INFO] Reaktora uzbūves secība: [INFO] Bez nosaukuma - org.codehaus.mojo: b: pom: 2 [INFO] Bez nosaukuma - org.codehaus.mojo: a: jar: 2 Maven dzīves cikls tagad tiks izpildīts līdz dzīves cikla fāzei, kas norādīta pareizā secībā; tas ir, katrs artefakts tiek veidots pa vienam, un, ja viena artefakta gadījumā vispirms ir jāuzbūvē cits, tas arī būs.
Piezīme par mantojumu pret summēšanu
Mantošana un apkopošana rada jauku dinamiku, lai kontrolētu būvējumus, izmantojot vienu, augsta līmeņa POM. Jūs bieži redzēsiet projektus, kas ir gan vecāki, gan multimoduli, piemēram, iepriekš minēto piemēru. Viņu savstarpējā papildināmība padara viņus par dabisku spēli. Pat Maven 2 projekta kodols iet caur vienu vecāku / vairāku moduļu POM org.apache.maven: maven, tāpēc Maven 2 projekta izveidi var veikt ar vienu komandu: mvn sastādīt. Lai gan multimoduli un vecāki tiek izmantoti kopā, tie tomēr nav viens un tas pats, un tos nevajadzētu jaukt. POM projekts (kas darbojas kā vecāks) var būt mantots, taču šis vecāku projekts ne vienmēr apkopo moduļus. Un otrādi, POM projekts var apvienot projektus, kas no tā nav mantoti.
Kad visi četri vienādojuma gabali ir salikti kopā, cerams, ka jūs redzēsiet Maven 2 attiecību mehānisma spēku, kā parādīts 7. attēlā.
Maven dod mums jauku ietvaru projektu savstarpējai saistīšanai, un, izmantojot šīs attiecības, mēs varam izveidot spraudņus, kurus var atkārtoti izmantot jebkurš projekts, ievērojot Mavenas konvencijas. Bet spēja vadīt projekta attiecības ir tikai daļa no kopējā Maven vienādojuma. Pārējais POM nav saistīts ar citiem projektiem, bet gan ar tā uzbūves iestatījumiem, informāciju un vidi. Ātri izprotot to, kā projekti savstarpēji ir savstarpēji saistīti, sāksim aplūkot, kā POM satur informāciju par projektu.
