Maven 2 - Build Lifecycle #1

Der rich­tige Ansatz für ein Build­ser­ver muss erst ein­mal gefun­den wer­den. Ich möchte hier nicht auf alle ein­ge­hen son­dern gleich ein aus­ge­wähl­tes Sys­tem vor­stel­len. Es han­delt sich dabei um Maven¹. Die­ses Sys­tem basiert auf Plugins und stellt eine masse an Mög­lich­kei­ten bereit.

Wer sei­nen Build­pro­zess² auto­ma­ti­sie­ren möchte sollte sich damit ver­traut machen. So ein Maven-Projekt bringt von haus aus eine eigene Kon­ven­tio­nen mit sich die man nach Mög­lich­keit auch nut­zen sollte. Aber auch für Pro­jekte die Tech­nisch an eine bestimmte Struk­tur gebun­den sind, gibt es Lösungs­an­sätze. Eines sollte man über Maven wis­sen und sich auch immer im kla­ren sein, es gibt kei­nen Stan­dard. Wie ein Build Lifecy­cle aus­se­hen sollte, rich­tet sich immer nach den Projekt(en).

Maven bie­tet aber ein Stan­dard Build­pro­zess aus fol­gen­den Plu­gin an:

1. clean (Säu­bern)
2. vali­date (Validieren)
3. com­pile (Kompilieren)
4. test (Tes­ten)
5. package (Ver­pa­cken)
6. integration-test (Integrations-Tests)
7. verify (Gül­tig­keits­prü­fung)
8. install (Instal­lie­ren im loka­len Repository)
9. deploy (Instal­lie­ren im ent­fern­ten Repository)
10. site (Gene­rie­rung der Dokumentation)

Jede Phase stellt ein Plu­gin dar und über­nimmt ver­schie­dene Auf­ga­ben und defi­niert letzt­end­lich den Build­pro­zess. Im fol­gen­den die ein­zel­nen Schritte im Detail:

1. Ent­fernt Arte­fakte³ von vor­he­ri­gen Builds
2. Vali­diert⁴ das Pro­jekt auf Kor­rekt­heit und prüft ob alle Abhän­gig­kei­ten⁵ gege­ben sind
3. Kom­pi­liert den Programmcode
4. Tes­tet den kom­pi­lier­ten Pro­gramm­code mit Hilfe eines unit-testing-framework⁶. Diese Tests soll­ten nicht ver­lan­gen, dass der Code gepackt (packa­ged) oder aus­ge­lie­fert (deployed) sein muss.
5. Fasst den kom­pi­lier­ten Code in einem bestimm­ten For­mat zusam­men, z.b. zu einer jar.
6. Inte­gra­ti­ons­tests auf ande­ren Sys­te­men. Es wird dabei getes­tet ob das Pro­jekt auf dem Ziel­sys­tem funk­ti­ons­tüch­tig ist.
7. Hier kön­nen sons­tige Tests ange­sto­ßen wer­den die prü­fen ob das Pro­jekt gül­tig und ggf. bestimmte Qua­li­täts­kri­te­rien erfüllt sind.
8. Instal­liert das Package in das lokale Repo­sitory⁷, wor­auf lokale Pro­jekte in Abhän­gig­keit dies nut­zen können.
9. Instal­liert das Package in ein ent­fern­tes Repo­sitory. Dies wird ver­wen­det um sta­bile Ver­sio­nen ande­ren Pro­gram­mie­rern zu ver­fü­gung zu stellen.
10. Erstellt eine Projekt-Dokumentation. Eben­falls ist es hier mög­lich Java­Docs oder Code-Duplicates anzei­gen zu lassen.

Es ist für den Anfang sicher etwas viel. Wenn man sich aber etwas ein­ge­le­sen hat und lang­sam dahin­ter steigt, lässt sich dar­aus eine Menge machen. Und darum geht es in die­ser Sto­ry­line, einen auto­ma­ti­schen Build­pro­zess aufzubauen.

1. http://maven.apache.org/ [↩]
2. http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html [↩]
3. Arte­fakte sind bei­spiels­weise jar- oder zip-Pakete die durch das kom­pi­lie­ren erstellt wer­den kön­nen. Diese sind zu meist mit einer Ver­sio­nie­rung ver­se­hen. Diese Arte­fakte kön­nen von ande­ren Pro­jek­ten in Abhän­gig­keit genutzt und ein­ge­setzt wer­den. [↩]
4. Damit prüft das Plu­gin durch ob im Pro­gramm­code Feh­ler ent­ha­ten sind. Das beste Bei­spiel dafür sind Errors. [↩]
5. Pro­jekte grei­fen i.d.R. auf andere Resour­cen zu und damit wird geprüft ob diese vor­han­den sind. [↩]
6. Ein bekann­tes Frame­work ist JUnit: http://www.junit.org/ [↩]
7. Stellt ein Ver­zeich­nis da, wo sämt­li­che Maven und haus­ei­ge­nen Pro­jekte ver­wal­tet und genutzt wer­den kön­nen [↩]