Po co mi MAVEN do szczęscia?

Zaczynając projekt 99CRM moje doświadczenie programistyczne opierało się na narzędziach jakie pokazano mi na uczelni. IDE Ecplise, Visual Studio, Android Studio… To kompletne podstawy, dlatego żeby nadrobić zaległości zdecydowałem dotknąć chociaż narzędzi, jakich używają programiści zawodowi. Jednym z takich narzędzi jest MAVEN.

MAVEN – to narzędzie firmy Apache, która pierwszą wersję opublikowała prawie 15 lat temu (2002-03-30 – Maven 1.0-beta-2). Czemu piszę na wstępie o tej dacie? Bo byłem w wielkim szoku, że w roku 2017 pierwszy raz słyszę o tym narzędziu, które od 2002 roku gdzieś tam sobie było, ktoś go używał itp. Oczywiście to trochę i moja wina, że nie zgłębiałem narzędzi i sposobów budowania oprogramowania, ale do cholery czemu uczelnie wyższe nie wspominają o nich. Akurat zdarzyło mi się uczęszczać do uczelni prywatnej, może winą tam jest zły dobór wykładowców.

W jednym zdaniu jak określiłbym wykorzystanie tego narzędzia… Hmmm… AUTOMATYZACJA budowania oprogramowania. To pojęcie podobno dobrze określa to narzędzie w całości. Ale, z uwagi na mój początkowy poziom zaawansowania budowania aplikacji narazie określę to narzędzie w inny sposób: AUTOMATYZACJA konfigurowania środowiska programistycznego. Tak. A dokładnie mam tu na myśli plik pom.xml i zależności – dependencies. Jeśli jesteś na poziomie java-core pewnie nie musiałeś dogrywać do projektu zewnętrznych jarów, no może kiedyś mysql-connector. Ale jak bawiłeś się Springiem, może nawet Hiberate, to na pewno zależności nie są Ci obce. Przed mavenem zewnętrzne jary wrzucałem zawsze do folderu /lib, i potem Add to Build Path i już mieliśmy zależności w naszym projekcie. Wydaje się proste i w sumie bezproblemowe. No nie do końca. Może się zdarzyć, że przy przeniesieniu projektu zależności trzeba będzie konfigurować od początku. Podczas konfiguracji może dojść do problemów, załączona nie ta wersja, brak potrzebnego jara itp.

Maven daje możliwość automatycznego pobierania zależności (zewnętrznych plików jar) do projektu. użytkownik nie musi martwić się, że brakuje mu jara odpowiadającego za połączenie z bazą MySql, albo jarów Springowych. Wszystko robi za nas maven. No dobra… ale skąd maven wie co potrzebujemy? Analizuje nasz kode i błedy? No nie… Programista musi się na początku trochę wysilić, żeby dane zależności okreslić.

Plik pom.xml (POM – czyli Project Object Model) zawiera m.in opis niezbędnych zależności w projekcie. Określane są one w tagu <dependencies>, a każda zależność oddzielnie w tagu <dependency>. Dla connectora MySql zależność będzie wyglądała tak:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>99CRM</groupId>
  <artifactId>99CRM</artifactId>
  <version>0.0.1-SNAPSHOT</version>

    <dependencies>

        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
            <version>5.1.6</version>
        </dependency>

    </dependencies>

    <properties>
        <spring.version>3.2.3.RELEASE</spring.version>
    </properties>
</project>

Określenie connectora MySql, jak i również innych zależności, sprowadza się do podanie jego trzech atrybutów niezbędnych do pobrania odpowiedniego pliku jar: groupID oraz artifactId identyfikuje niezbędny pakiet, a pole version określa jego wersję. Dzięki podaniu tych , do naszego projektu wskakuje odpowiednia zależność.

Wszystkie możliwe zależności można przeglądać w repozytorium mavena, a tutaj podgląd MySQL Connector/J 5.1.6, którego użyłem w projekcie do komunikacji z bazą danych MySql. Jeśli masz problem, z odpowiednim określeniem wspomnianych wyżej atrybutów, możesz wyszukać zależność w repozytorium, a tam maven przygotował gotowy kod xml.

Oprócz automatycznego pobierania zależności do projektu, maven tworzy automatycznie strukturę projektu.  Ustandaryzowana struktura czyni nasz projekt bardziej przystępny dla innych programistów. Jeden rzut oka na katalogi projektu i każdy wie gdzie szukać modelu klasy, gdzie szukać pliku DAO (o DAO niebawem szerszy artykuł), a gdzie serwisów. Gdzie są testy, a gdzie skompilowany projekt. Maven twory katalogi za nas podczas generowania projektu.

Ok, trochę teorii za nami. W następnym artykule stworzymy nowy projekt przy użyciu mavena. Czym byłaby teoria, bez praktyki 🙂

Czytelników,, którzy liczyli na artykuł o z diagramem klas chciałem uspokoić, że takowy się pojawi, tyle że z delikatnym opóźnieniem. Obecnie skupiłem się na konfiguracji środowiska i testowaniu frameworków. Diagram  klas na pewno się pojawi 🙂

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *