My Developer Toolkit II
N pierwszy ogień idą najważniejsze narzędzia związane z programowaniem w Javie. Znaczy się kompilatory, a tak na prawdę narzędzia wspomagające proces kompilacji. Mówiąc o javie mamy zazwyczaj na myśli dwa takowe. AntW i MavenW. Mało kto pamięta, że jest jeszcze makeW, ale jako, że jest on tak samo przydatny jako konsola to nie będę go tu omawiał. Warto jednak zaznaczyć, że make jest jedynym narzędziem ujętym w ramach rekomendacji i norm IEEE. Dlatego też w ostateczności może być używany w środowiskach, gdzie mamy ograniczony dostęp do innych narzędzi.
Apache Ant – mrówa zasuwa
Apache Ant jest najstarszym i najpopularniejszym narzędziem wspomagającym budowanie projektów. Przyjął się jako standard w środowisku i jest używany jako domyślne narzędzie w NetBeans.
Zasada działania opiera się na pliku build.xml i pomocniczych plikach .properties z konfiguracją. Plik jest przetwarzany na wzór skryptu powłoki. Mamy do dyspozycji podstawowe polecenia związane z operacjami na plikach i folderach. Dodatkowo mamy dostęp do narzędzi javy kompilatora, javadoc czy też keytoola. Całość zamknięta w ramach jednego skryptu xml.
Wygoda użytkowania tego narzędzia jest niezła. Stosunkowo łatwo tworzy się skrypty i nimi zarządza. Całość jest bardzo intuicyjna i jeżeli zespół używa spójnego nazewnictwa to nie powinno być problemów. Niestety w „czystym” ancie nie ma modułu do zarządzania zależnościami. W 2005 roku powstała biblioteka Ivy, która pozwala na zarządzanie zależnościami w sposób podobny do tego znanego z mavena.
Podsumowując, Ant jest narzędziem dobrym, bardzo elastycznym, ale brakuje mu tego czegoś. Każda rzecz trzeba pisać z palucha i nie ma z definicji zarządzania zależnościami.
Apache Maven – Miał Architekt Vizje, Albo Nie
Apache Maven powstał w 2002 roku i z założenia miał byś czymś nowym i lepszym od Anta. Pierwsza wersja była dość toporna, sposób zarządzania zależnościami był źle zaprojektowany, a całość charakteryzowała się wysokim współczynnikiem WTF/s. Dlatego też otrzymaliśmy Maven 2, który jest znacznie lepszy od poprzednika, a ponad to na głowę bije Anta.
Cała idea mavena opiera się na pliku pom.xml. Nazwa pliku pochodzi od Project Object Model. I tu w sumie już wszystko wiadomo. Projekt jest traktowany jak obiekt posiadający pewne właściwości i zależności od innych obiektów. Inne obiekty to przede wszystkim wtyczki i artefakty. Główną zaletą mavena jest moduł zarządzania zależnościami. Istnieją repozytoria, w których znajdują się biblioteki. Zależność definiujemy w pliku pom.xml i odpowiedni mechanizm pobiera bibliotekę. Co ważne jest ona zapisywana w lokalnym repozytorium co pozwala na jej kolejne użycie bez konieczności ponownego ściągania. Dzięki systemowi wtyczek maven może zrobić wszystko. Począwszy od użycia niestandardowego kompilatora, poprzez testowanie jednostkowe kodu, pakowanie na wysłani na serwer i tworzeniu dokumentacji skończywszy. Warto tu zaznaczyć, że jak piszą sami twórcy Maven nie służy do generowania ładnych stron projektu, super dokumentacji. Nie jest też rozszerzeniem Anta. Jednakże dzięki systemowi wtyczek może spełniać i takie zadania.
Niestety są też wady. Po pierwsze repozytoria są publiczne co powoduje problemy z licencjami. Więcej na ten temat tu. Po drugie, brakuje mechanizmu przeszukiwania repozytoriów pośrednich. Po trzecie nie wszystkie pluginy robią dokładnie to czego oczekujemy. Przykładem niech będzie plugin do podpisywania jarów. On po prostu nie działa dobrze.
Podsumowując Maven jest narzędziem znacznie lepszym niż Ant. Jest lepiej przemyślany i nowocześniejszy. Pomimo pewnych braków można z nim żyć.
Podsumowanie właściwe
Używam w pracy i w domu zarówno Anta jak i Mavena. Narzędzia te nieźle się uzupełniają, ale zdecydowanie wygodniejszy jest Maven.
Poniżej kandydat na tabelę porównawczą (muszę ostylować, proszę o cierpliwość):