blog.grejpfrut.org

Od jakiegoś czasu pracując z m2 pod Eclipse używam m2eclipse plugin, oferuje on kilka przydatnych funkcjonalności:

• możemy obdarzyć projekt mavenową naturą, jest wizard który po wypełnieniu prostego formularza tworzy pom
• możemy przeglądać sobie lokalne i zdalne repozytoria w poszukiwaniu zależności,
• po ich wybraniu odpowiedni xml sam dodaje się do pom’a naszego projektu,
• poza tym m2 jest w Eclipse dostępny jako build tool zupełnie jak Ant

Na stronie projektu są dwa screencasty : instalacja, oraz użytkowanie. Jednym słowem prawie Netbeans

Skonfigurowałem sobie m2 tak, że katalog lokalnego repozytorium nie znajduję się w domyślnej lokalizacji userhome/.m2/repository tylko w tym samym katalogu co m2 M2HOME/repo. Jeżeli ktoś chciałby sobie zrobić coś podobnego, wystarczy odkomentować w M2HOME/conf/settings.xml znacznik localRepository i wpisać tam odpowiednią ścieżkę. Gdy zainstalowałem m2eclipse na komputerze w domu (w pracy m2 działa w domyślnej konfiguracji więc problemów z tą wtyczką nie miałem) Eclipse nie za bardzo chciał się pogodzić z nową sytuacją . Po wybraniu Maven2 w menu Window/Preferences Eclipse’a, pojawiał się komunikat o błędzie. Poszukałem trochę i znalazłem w czym problem .

Problem dotyczy błędu MNGECLIPSE-124, m2eclipse plugin ma w sobie zawartego całego m2. Zgodnie z tym co napisał w komentarzu do tego zadania William Ferguson wygląda na, że zawarty w pluginie m2 nie czyta konfiguracji z M2_HOME/conf/settings.xml. Jeżeli ktoś chce wiedzieć więcej odsyłam do komentarzy do tego bug’a. Najprostszym rozwiązaniem tego problemu jest wrzucenie kopii M2_HOME/conf/settings.xml do userhome/.m2/ u mnie po tej operacji plugin śmiga.

Wprawdzie wywiad nie jest już pierwszej świeżości, ale dopiero teraz znalazłem chwilę żeby sobie ściągnąć tego podcast’a. Myśle, że warto tego w wolnej chwili posłuchać (zresztą jak większości podcast’ów z Java Posse). O czym jest mowa?

• Czym jest maven? jakie są podstawowe założenia i zastosowania
• Pytanie bumerang: maven vs ant
• Dlaczego warto przyjrzeć się bliżej maven’owi?
• Wzorce i konwencje w budowaniu projektów.
• Czy i jak maven zwiększa produktywność.
• Integracja istniejących skryptów ant’owych z maven’em.
• Różnice między m1.x i m2.
• Jak komercyjne projekty odnoszą się do maven’a
• Integracja z IDE.
• Nad czym maven team pracuje (pracował )
• Jaką role w maven project pełni Mergere.

No i link Java Posse #070 – Interview with Brett Porter of Maven. Wygląda na to, że tematy związane z maven’em jednak jeszcze się pojawią w najbliższej przyszłości .

Gdy zaczynałem swoje przygody z maven’em wydawało mi się, że głównym powodem dla którego warto użyć w projekcie maven’a jest to że sam generuje stronę dla projektu . W m1.x można było za pomocą goal’a site wygenerować nie tylko stronę projektu, ale również (a może przede wszystkim) raporty oparte na statycznej analizie kodu, opis zależności, statystyki związane z repozytorium. W m2 część z raportów jest wciąż niedostępna, a żeby użyć innych musiałem posiłkować się wersjami pluginów wprost z repozytorium. Krok po kroku zbudujemy sobie taką stronkę…

Jak już wspomniałem do tworzenia strony w m2 używa się plugin’a site korzystając z projekty który wygenerowaliśmy w poprzednich postach możemy sprawdzić jak to działa. W katalogu głównym wystarczy wydać polecenie mvn site, m2 swoim zwyczajem ściągnie pół internetu . Gdy skończy w target/site będziemy mieli wygenerowaną stronkę dla naszego projektu. Rzeczy dotyczące samego projektu jak: adres strony, opis, adres repozytorium, deweloperzy którzy biorący udział w projekcie, zależności projektu należy umieścić w pom.xml (kompletna referencja tutaj naprawdę warto się zapoznać).

Czas dostosować stronkę do naszych potrzeb, jeżeli chcemy dodać trochę swoich własnych linków, jakąś dokumentację dotyczącą naszego projektu musimy stworzyć dodatkowy katalog w strukturze naszego projektu /src/site a w nim stworzyć plik site.xml. Przykładową zawartość (jak i całe objaśnienie możecie znaleźć tutaj) nie jest to specjalnie wyuzdane . Na tej samej stronie znajdziecie informacje także o katalogu /src/site/apt w którym przechowywana jest w formacie apt treść która będzie później umieszczona na stronie. APT czyli almost plain text to format który za pomocą kilku prostych konstrukcji (podobnie jak w wiki) pozwoli stworzyć przyzwoicie wyglądający dokument (zobacz tu). Site plugin pozwala tworzyć kilka wersji językowych naszej strony, wszystko dość dokładnie opisane na wspomnianej wyżej stronie. Znalazłem też na stronie samego pluginu kilka słów na temat tworzenia własnych skór dla generowanych przez m2 stron – zobacz tu

Teraz to co najsmaczniejsze – raporty z statycznych analiz kodu. W m2 udało mi się użyć następujących raportów: findbugs, checkstyle, pmd, cpd. Checkstyle w czasach gdy nawet dziecko wie do czego służy ctrl+shift+f pod eclipse traci trochę na znaczeniu, nie mniej wydaje mi się wart tych kilku linijek xml’a w pom’ie. To co zostanie wygenerowane nie będzie miało pełnej wartości jeżeli nie dorzucimy jeszcze dwóch rzeczy: jxr i javadoc. Pierwszy z nich generuje html’ową wersje kodu źródłowego tak aby można było odwoływać się do konkretnej linii. Jest to dośc przydatne ponieważ pozostałe raporty (jak np. pmd) w wygenerowanych zestawieniach linkują konkretne miejsce w kodzie i możemy zobaczyć o co dokładnie chodzi. Javadoc nie wymaga chyba komentarza . Aby włączyć te raporty do strony naszego projektu musimy w pom.xml stworzyć sekcje reporting. Przykładową realizację możecie znaleźć w tutaj. Należy zwrócić uwagę na jeszcze jedną sekcje

 <pluginRepositories>
    <pluginRepository>
      <id>codehaus-snapshots</id>
      <name>Codehaus snapshots</name>
      <url>http://snapshots.maven.codehaus.org/maven2/</url>
    </pluginRepository>
  </pluginRepositories>

Tak jak mówiłem na samym początku w chwili gdy tworzyłem tego pom’a bez snapshotów nie dało się tych raportów stworzyć, być teraz problem jest już nieaktualny. Gdy już przygotujemy naszego pom’a mvn site i pozstaje już tylko poprawiać błędy znalezione przez m2 . Więcej o pluginie raportującym tutaj. Ostatnia praktyczna rada, często wykonanie mvn site może trwać dłuższą chwilę, jeżeli zależy nam na wynikach konkretnego raportu. Warto wiedzieć, że każdy raport można wywołać z linii poleceń np. mvn checkstyle:checkstyle.

To ostatni post nt. m2 – przynajmniej narazie myśle, że po zapoznaniu się z linkami które umieściłem w tych postach każdy zyska już odpowiednią biegłość w wyszukiwaniu informacji na stronach mavena. Mam nadzieje, że komuś się to przyda.

Już od kilku miesięcy można ściągnąć darmową książke nt. m2, “Better Builds with Maven” to kooperacja ludzi którzy maven’a tworzą, więc teoretycznie informacje z pierwszej ręki.

W październiku ukazała się wersja 1.1 autorzy obiecują, że wiele spośród błędów które pojawiły się w oryginale zostało poprawionych, zdanie nt. tej książki ludzie mają różne. Na pierwszy rzut oka książka bardzo przypomina to co można znaleźć na stronach maven.apache.org, zobaczymy co będzie przy bliższym poznaniu. Można ssać stąd.

Zarządzanie zależnościami w m2 opisałem już szczątkowo w poprzednich postach, dokładny opis z przykładami możecie znaleźć na tej stronie.

struktura repozytorium Maven

W tym poście chciałbym krótko omówić strukturę repozytorium m2, mimo istnienia kilku centralnych, dużych repozytoriów warto dla swojego projektu stworzyć własne. Powodów po temu może być kilka:

• nasz projekt używa bibliotek których na ibiblio.org próżno szukać (np. jakiś zapomniany projekt studencki )
• stworzenie repozytorium na projektowym serwerze przypuszczalnie znacznie przyspieszy download artefaktów (ibiblio bywa obciążone)
• w przypadku awarii centralnego repozytorium (co miało jakiś czas temu miejsce ) możemy spokojnie dalej pracować

Czego potrzeba zeby stworzyc repozytorium maven2? Naprawde niewiele: trochę miejsca na serwerze, potrzebujemy katalog dostępny (dajacy sie wylistować) z www. Teraz trzeba wrzucić jar’y i pliki pom tak aby były zgodne z ustalona struktura katalogow. Korzeń zaprezentowanego poniżej systemu plików (lucene) to groupId zależności, na groupId nie musi się składać tylko jeden poziom katalogów (w przypadku lucene wygląda to tak: org/apache/lucene/lucene-core). Lucene-core to nazwa artefaktu, na poziomie niżej znajdują się konkretne wersje. Każdy artefakt musi mieć dołączoną sumę kontrolną w plikach md5, sha1. Każdy czyli: pom, jar i wszystko inne (xml). Co zresztą widać na powyższym obrazku.

Dwa słowa o plikach metadanych, w katalogu głównym wyglądać on może tak:

  <metadata>
     <groupId>lucene</groupId>
     <artifactId>lucene-core</artifactId>
     <version>2.0.0</version>
     <versioning>
  	   <versions>
            <version>2.0.0</version>
            <version>1.9.1</version>
           </versions>
     </versioning>
   </metadata>

w katalogu wersji troche inaczej:

   <metadata>
     <groupId>lucene</groupId>
     <artifactId>lucene-core</artifactId>
     <version>2.0.0</version>
   </metadata>

W m2 można zadeklarować zakres zależności, w polu version artefaktu wpisujemy np. [1.2,1.3] co oznacza, że nasz projekt będzie działać z wersjami 1.2 lub 1.3. Domyślnie m2 zaciągnie najnowszą wersje biblioteki, ale gdyby któraś z zależności przechodnich określała w swoim pom’ie, że z najnowszą wersją nie poleci m2 wybierze tą z która działać będzie wszystko. (więcej tu)Padło magiczne hasło… zależności przechodnie! grr.. Każdy pewnie kiedyś gdzieś zobaczył ClassNotFoundException , dodaliśmy do naszego projektu bibliotekę, a po uruchomieniu zamiast efektów widzimy wyjątki. M2 oferuje swój całkiem sprawny mechanizm zawiadywania zależnościami przechodnimi dzięki temu, że do każdego projektu w repo dołączany jest pom z opisem zależności każdego projektu, m2 może podczas ściągania zależności przejrzeć sobie je i dodać zależności zależności .

Podsumowując musimy stworzyć odpowiednią strukturę katalogów, dodać pliki metadanych, dołączyć do tego wszystkiego sumy kontrolne i wrzucić na serwer. Wbrew pozorom jest trochę z tym roboty, istnieje wtyczka repository która udostępnia polecenie bundle-create. Nie użyłem jej nigdy, wymaga ona wypełnienia w pom.xml takich rzeczy jak scm, licencja (opis tutaj). Strukturę katalogów tworzę więc ręcznie a do podpisywania plików stworzyłem sobie prosty plik ant’owy (gdyby ktoś znał jakiś prostszy sposób, to dajcie znać )

Gdy stworzymy już nasze projektowe repozytorium musimy jeszcze dodać jedną rzecz w pom.xml projektu:

    <repositories>
       <repository>
         <id>our-project-repo</id>
         <name>Our project repo</name>
         <url>http://our.project.org/maven_repo</url>
       </repository>
     </repositories>

To w zasadzie wszystko, jest jeszcze jedna ciekawostka w m2 można też używać repozytoriów m1.x. Zauważyłem to dopiero przy przeglądaniu referencji do pom.xml. W sekcji repository jest możliwość wyspecyfikowania tag’a layout możemy mu przypisać wartość default albo legacy. Stosunkowo prościej stworzyć repo w starym formacie (nie ma sum kontrolnych, plików metadanych), ale też takie repo nie obsłuży przechodnich zależności czy zakresów wersji. Coś za coś .

Hmmm… maven to elastyczne narzędzie, żeby osiągnąć zamierzony cel trzeba czasami przebić się przez całkiem sporo nakonfigurować. W dzisiejszym odcinku będzie o trzech pluginach: assembly, jar i antrun. W maven 1.x było wszechobecne Jelly, chciałem się przekonać jak będzie wyglądało tworzenie wersji dystrybucyjnej w m2.

Zacznijmy od projektu który wygenerowaliśmy poprzednim razem, jeżeli chcielibyśmy wygenerować teraz jar’a wystarczy wydać polecenie mvn package. M2 bez żadnych problemów stworzy nam jar’a, teraz dodajmy do naszego projektu jakieś zasoby. Aby zasoby były bezproblemowo dołączone do jar’a musimy stworzyć katalog $project.base.dir/src/main/resources i wszystkie zasoby wrzucać właśnie do niego. Po utworzeniu jar’a zostaną one przekopiowane do podstawowej ścieżki archiwum.

Gdy zajdzie konieczność zmiany manifestu jar’a to wedle mojej skromnej wiedzy musimy pogrzebać trochę w konfiguracji maven-jar-plugin. Można to zrobić specyfikując w pom.xml następujący blok:

<build>
     ...
    <plugins>
     <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-jar-plugin</artifactId>
      <configuration>
	 <archive>
	   <manifest>
	     <addClasspath>true</addClasspath>
	     <addExtensions>true</addExtensions>
	     <classpathPrefix>./lib/</classpathPrefix>
 	     <mainClass>org.grejpfrut.App</mainClass>
             <packageName>org.grejpfrut</packageName>
	   </manifest>
 	 </archive>
      </configuration>
     </plugin>
    </plugins>
    ...

  <build>

Cała magia siedzi wewnątrz sekcji <configuration> tutaj specyfikujemy, że do manifestu ma być dodana informacja o classpath, tag classpathPrefix instruuje maven-jar-plugin aby przed każdą zależnością dostawiał ścieżke ./lib (np. ./lib/log4j-1.2.13.jar). Takie rozwiązanie pozwala utrzymać porządek w katalogu dystrybucji i rozdzielić główny jar od jego zależności. Pozostałe parametry nie wymagają wyjaśnień.

Aby sprawdzić poprawność manifestu możemy użyć kodu App.java który podałem w poście o maven 1.x, należy uaktualnić plik pom.xml o opis log4j w sekcji dependencies i wydać polecenie mvn package. Po rozpakowaniu jar’a możemy podejrzeć plik Meta-inf/Manifest.mf. W katalogu Meta-inf maven umieszcza kopie pom.xml oraz plik pom.properties który zawiera najbardziej podstawowe informacje o projekcie (wersja, artifactId, groupId). Po co te pliki?

“The pom.xml and pom.properties files are packaged up in the JAR so that each artifact produced by Maven is self-describing and also allows you to utilize the metadata in your own application if the need arises. One simple use might be to retrieve the version of your application.”maven.apache.org

Wyobrażmy sobie jednak, że pojawia się kolejny problem… mianowicie w przypadku zasobów związanych z umiedzynarodowieniem naszej aplikacji bywa, że properties muszą znajdować się w katalogu src w katalogu związanym z odpowiednim pakietem. Problem ten wystąpi zawsze gdy będziemy chcieli umieścić zasoby w katalogu innym niż wposmniane wcześniej src/main/resources (bądź działającym na tej podobnej zasadzie src/test/resources). W czasie tworzenia jar’a m2 po prostu nie przekopiuje niczego poza skompilowanymi klasami. Zastosowane przez nas rozwiązanie zostało oparte o ant’a.

W m2 wszystko związane jest z fazami i cyklem zycia oprogramowania. W starym mavenie specyfikowaliśmy sekcje post i pregoal w maven.xml. W m2 aby użyć jakiegoś celu/wtyczki który nie należy do zdefiniowanego cyklu budowania musimy go zadeklarować w pom.xml. Tak też musimy postąpić z maven-antrun-plugin.

    <plugin>
      <artifactId>maven-antrun-plugin</artifactId>
      <executions>
        <execution>
	   <phase>compile</phase>
	   <configuration>
	    <tasks>
		<copy todir="${basedir}/target/classes/">
	  	  <fileset dir="${basedir}/src/main/java/">
		     <include name="**/lang/*.properties">
	 	  </fileset>
		</copy>
	    </tasks>
	   </configuration>
	   <goals>
	     <goal>run</goal>
	   </goals>
	 </execution>
      </executions>
     </plugin>

Plugin antrun pozwala wykonać dowolne zadania ant’a i przypisać je do konkretnego etapu tworzenia oprogramowania. Widzimy tutaj prosty skrypt który wykonuje to czego m2 nie robi.

Jesteśmy coraz bliżej działającej dystrybucji . Do tworzenia dystrybucji używa się wtyczki assembly. Jest ona całkiem przyzwoicie opisana, więc w razie pytań warto tam zajrzeć. Poza tym naprawde dobrze opisał to Jacek Laskowski. Mój opis będzie więc zgrubny, ogranicze się tylko do wypisania tego co zmieniłem w stosunku do tego co zaporoponował Jacek. Oto co zostało dodane do pom.xml:

       <plugin>
	 <artifactId>maven-assembly-plugin</artifactId>
	 <version>2.0.1</version>
	 <configuration>
	   <descriptors>
  	     <descriptor>src/main/assembly/jar.xml</descriptor>
	   </descriptors>
 	   <finalName>${artifactId}</finalName>
	 </configuration>
	</plugin>

Jedyną ciekawą rzeczą w tym kawałku xml’a jest specyfikacja deskryptora. Standardowo deskryptory dla assembly składowane są w src/main/assembly, nasz projekt może być dystrybuowany na więcej niż jeden sposobów. To w jaki sposób każdy z nich będzie tworzony zależy właśnie od opisu. Dokładny opis możliwości i predefiniowanych deskryptorów na stronie pluginu.

Deskryptor jar.xml musi zostać dodany do projektu w ścieżce która specyfikujemy w pom.xml.

    <assembly>
        <id>zip</id>
	<formats>
	 <format>jar</format>
	</formats>
	<includeBaseDirectory>false</includeBaseDirectory>
	<fileSets>
 	  <fileSet>
           <directory>target</directory>
           <outputDirectory></outputDirectory>
            <includes>
             <include>*.jar</include>
            </includes>
           </fileSet>
           <fileSet>
	     <directory>lib</directory>
             <outputDirectory></outputDirectory>
             <includes>
              <include>*.dll</include>
             </includes>
           </fileSet>
        </fileSets>
       <dependencySets>
         <dependencySet>
           <outputDirectory>/lib</outputDirectory>
           <unpack>false</unpack>
           <scope>runtime</scope>
           </dependencySet>
         </dependencySets>
       </assembly>

Tu będzie troche komentarza, określamy format dystrybucji (oprócz zip’a może być jeszcze chyba tar i jar) tutaj zip. Pierwszy fileset załącza do dystrybucji nasz jar, wygenerowany gdzieś około pierwszego akapitu tego artykułu. Znajdzie sie on w katalogu /target/ i zostanie przekopiowany do głównego katalogu dystrybucji. W Weed używamy kilku dll’i, który na codzień mieszkają w $project.base.dir/lib zostaną również przekopiowane do katalogu lib. Następnie włączamy do dystrybucji wszystkie zależności, zgodnie z opisaną wcześniej filozofią zostaną one przeniesione do lib. Przy specyfikacji dependencySet ważne jest aby zaznaczyć jaki scope mają mieć zależności włączane do dist’a (tutaj np. nie zostanie włączony junit który ma scope test).

To właściwie wszystko . Prawda jakie to proste . teraz mvn assembly:assembly dostaniemy ładnego zip’a którego po rozpakowaniu możemy uruchomić gdzie nam się spodoba. Drugi wart zapamiętania cel to mvn assembly:directory tworzy on całą strukturę, ale nie pakuje jej do zip’a. Niezłe do testowania. Uruchamiamy : java -jar test-1.0-SNAPSHOT.jar

Problem: niewiem czemu zależności które mają scope : system, nie są uwzględniane w manifeście przy tworzeniu jar’a. jeżeli ktoś wie dlaczego i jak sobie z tym poradzić będę wdzięczny.

Podobnie jak poprzednio również i ten krótki artykulik będzie pewną syntezą materiałów szkoleniowych. W kilku zdaniach chciałem napisać o tym co w Maven 2 jest takie inne w porównaniu z Maven 1.x. Nie będzie to doglębna analiza, dysponując pewną wiedzą nt. m1.x chciałem stworzyć prosty projekt w m2. Trzeba przyznać, że na stronach Maven’a znajduje się sporo bardzo dobrych materiałów właściwie nie potrzeba szukać nigdzie indziej wszystko co potrzebne da się tam znaleźć. Bardzo ciekawe artykuły opublikował też na swoim blogu Jacek Laskowski jeżeli chcesz wiedzieć więcej warto też zajrzeć do niego.

• Tworzenie szkieletu projektu. W 1.x służyło do tego polecenie maven genapp teraz analogiczne rzeczy robi mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app. Jak widać nie maven tylko mvn . W m2 zrezygnowano z Jelly, w związku z tym wszystkie ciężkie parsery xml’a i inne cuda potrzebne aby egzekować kod Jelly zostały wycięte. Wszystkie pluginy pisane są Javie i właśnie dlatego parametry dla plugin’u są podawane w ten a nie w inny sposób (-D…). (zapraszam do zapoznania się z tym)
• Deskryptor projektu już nie nazywa się project.xml tylko pom.xml zmieniła się też trochę składnia tego pliku. Aby wygenerować deskryptor Eclipse’y, należy wydać polecenie: mvn eclipse:eclipse. Po imporcie do eclipse konieczne będzie dodanie zmiennej classpath, można to załatwić z linii poleceń: mvn -Declipse.workspace=[ścieżka-do-przestrzeni-roboczej-Eclipse] eclipse:add-maven-repo.

Teraz kilka drogowskazów:

• dodawanie zasobów do jar’a
• instalowanie jar’ów w lokalnym repo

Nic co tu opisałem właściwie nie wyszło poza informacje zawarte w Getting Started. Polecam też resztę tutoriali.

Materiał ten powstał na potrzeby projektu Weed , chciałem to trochę poukładać, dopracować i dlatego publikuje to ponownie jako wpis na blogu. W obecnej sytuacji zaczynanie projektu w oparciu o maven 1.x mija się z celem. Wersja 1.x jest zasadniczo różna od aktualnej gałęzi projektu, ale być może zawarte tu informacje przydadzą się podczas grzebania w źródłach z jakiegoś już istniejącego projektu który właśnie z 1.x korzysta.

Zaczynamy, na początek potrzebujemy ściągnąć sobie maven’a – stąd. Proces instalacji został opisany dość dobrze na stronie. Nie jest to nic specjalnie wyzudanego . Po pomyślnym zakończeniu instalacji, czas na stworzenie pierwszego projektu. Wybierz katalog w którym masz prawa do zapisu i uruchom konsolę. Prawdopodobnie trzeba będzie ustawić zmienną PATH, żeby mavena można było wołać zewsząd. Wpisz maven genapp, wynikiem działania tego polecenia będzie szkielet aplikacji. Przykładowa aplikacja zawiera jedną klasę wykonywalną i test dla tej klasy, możemy też przyjrzeć się plikowi project.xml, który jest jądrem każdego projektu mavenowego.

Teraz czas na integracje z Eclipse’m, projekt który wygenerowaliśmy nie da się zaimportować do naszego ulubionego IDE. Konieczne jest wygenerowanie deskryptorów, oczywiście maven zrobi to za nas w katalogu głównym projektu wywołujemy maven eclipse. Wszystko jest już prawie gotowe do pracy, importujemy projekt do Eclipse’a (import existing project into workspace…).

Maven wprowadza bardzo ciekawy sposób zarządzania zależnościami w projektach, najlepiej zilustruje to prosty przykład. Dodamy do naszej aplikacji logowanie. Czym są logger’y i po co go używać? Wypisywanie komunikatów na standardowe wyjście jest bardzo niefajne, wiedzieli już o tym programiści C (strumienie suxx ). W poważniejszych zastosowaniach zaleca się stosowanie jakiejś biblioteki logującej np. log4j.
Otwórz plik project.xml i dopisz następujące linie (po tagu </developers>)

 <dependencies>
  <dependency>
   <groupId>log4j</groupId>
   <artifactId>log4j</artifactId>
   <version>1.2.13</version>
  </dependency>
</dependencies>

Zmieńmy też odrobine App.java, powinien on wyglądać tak:

import org.apache.log4j.BasicConfigurator;
import org.apache.log4j.Logger;

/**
 * Hello world!
 *
 * @author <a href="http://rose.man.poznan.pl/%7Emaneo/maven/jason@zenplex.com">Jason van Zyl</a>
 *
 */
public class App
{

    private static Logger logger = Logger.getLogger(App.class);

    public static void main( String[] args )
    {
        BasicConfigurator.configure();
        logger.info("hello world");
    }
}
 

Wykonaj teraz polecenie (katalog główny projektu, konsola systemowa:)): maven clean java:compile.Maven sam spróbuje ściągnąć brakującą bibliotekę z zdalnego repozytorium*.

Tak właśnie wygląda pełen cykl dodawania zależności, nie musimy trzymać bibliotek w cvs/svn są one potrzebne tylko na etapie kompilacji (ewentualnie testowania). Oszczędzamy miejsce, wszystkie zależności są wersjonowane, sama struktura opisu w project.xml u pozwala wyspecyfikować skąd- w przypadku braku danej biblioteki w repo ściągnąc, można ją ściągnąc. Maven nie zawsze będzie ściągał deklarowane przez nas jar’y. Po instalacji na naszym komputerze zostaje stworzone lokalne repozytorium zależności, tam przechowywane są wszystkie zależności. Jeżeli ponownie użyjemy log4j w jakimś innym naszym projekcie maven nie będzie ściągał go ponownie tylko posłuży się tym co ma w lokalnym repo (więcej o repozytoriach tutaj). Jedna uwaga o zdalnych repozytoriach, to z jakich będzie korzystał maven, możemy określić za pomocą zmiennej maven.repo.remote którą ustawiamy w pliku project.properties (lub build.properties) np. maven.repo.remote=http://public.planetmirror.com/pub/maven/,http://www.ibiblio.org/maven/

Może się zdarzyć, że szukanej przez nas biblioteki/jar’a nie ma w zdalnym repozytorium które jest domyślnie ustawione w maven. Tak jak pisałem, jeżeli nie nie uda się ściągnąć potrzebnej biblioteki należy zrobić to samemu i ściągniętego jar’a zainstalować w naszym lokalnym repozytorium zależności. Najprościej będzie to zrobić ręcznie, musimy umieścić jar’a w odpowiednim katalogu w lokalnym repozytorium. Weźmy naszego log4j’a w lokalnym repo musimy mieć katalog log4j (taki jak groupId w tagu dependency) w którym musimy mieć katalog jars i tam wrzucamy jar’a którego nazwa musi być zgodna z wzorem artifactId-version.jar (czyli log4j-1.2.13.jar). Gdzie znaleźć lokalne repo? Domyślnie znajduję się ono w katalogu domowym użytkownika w katalogu .maven/repository).

Po uaktulanieniu opisu projektu (project.xml) wpisz raz jeszcze: maven eclipse aby uaktualnić deskryptory projektu eclipse’owego.

Maven pozwala tworzyć własne skrypty dzięki którym możemy automatyzować wykonywanie pewnych czynności w projekcie. Skrypty te umieszczmy w pliku maven.xml (w tym samym katalogu gdzie znajduje się project.xml.

   <project xmlns:maven="jelly:maven" xmlns:j="jelly:core"
    xmlns:util="jelly:util" xmlns:x="jelly:xml" xmlns:ant="jelly:ant">

   <goal name="mygoal" prereqs="java:compile">
       <ant:copy file="${maven.src.dir}javamyfile.txt" tofile="${maven.build.dest}myfile.txt"/>
    </goal>
   </project>

Co to za język? Jelly! Osobiście nie jestem jego wielkim fanem, trzeba jednak przyznać, że da się w nim zrobić całkiem sporo. Stwórz plik myfile.txt w katalogu src\java\ i wpisz w konsoli : maven mygoal. Sporą część standardowych zadań w projekcie maven załatwia sam z siebie, więc jest spora szansa, że nie będzie potrzeby dotykania Jelly.

Kolejną fajną właściwością m. jest generowanie raportów ze statycznych analiz kodu, maven pozwala generować raporty za pomocą takich narzędzi jak FindBugs, PMD czy Simian. Chcąc skorzystać z raportów, niejako “przy okazji” wygenerujemy stronę www dla naszego projektu . W project.xml specyfikujemy jakie raporty chcemy wygenerować: (na samym końcu tuż przed tagiem </project>)

<reports>
  <report>maven-checkstyle-plugin</report>
  <report>maven-simian-plugin</report>
</reports>

Teraz aby wprowadzić słowa w czyn musimy wpisać w konsoli maven site. W katalogu /target/docs/index.html znajdziemy wyniki działania mavena. Zawartość sekcji Project info i Project reports możemy wyspecyfikować w pliku project.xml.

I to tyle na początek .