Maven - Na miękko

Pisałam już o tym, jak uruchomić aplikację w chmurze Pivotal oraz jak podłączyć do niej bazę danych. W tym odcinku pokażę, jak ułatwić sobie życie i bez wysiłku wdrażać nowe wersje aplikacji zaraz po ich poprawnym zbudowaniu. Wykorzystam do tego plugin Cloud Foundry Maven (Cloud Foundry ≈ Pivotal).

Cel

Wdrożenie nowej wersji w chmurze po wydaniu jednego polecenia. Spoiler – w tym wypadku będzie to:

mvn clean package cf:push

1	mvn clean package cf:push

Realizacja celu

Plugin w pom.xml

    <build>
        <plugins>
            ...
            <plugin>
                <groupId>org.cloudfoundry</groupId>
                <artifactId>cf-maven-plugin</artifactId>
                <version>1.1.3</version>
            </plugin>
            ...
        </plugins>
    </build>

<build>

...

<groupId>org.cloudfoundry</groupId>

<artifactId>cf-maven-plugin</artifactId>

</plugin>

...

</plugins>

</build>

Pierwszy tutorial, jak znalazłam w archiwach Cloud Foundry, twierdził, że pluginu nie ma w głównym repozytorium Mavena – konieczne miało być dodanie wpisu w sekcji pluginRepositories pliku pom.xml. Od tego czasu sytuacja uległa zmianie (https://mvnrepository.com/artifact/org.cloudfoundry/cf-maven-plugin) i nie trzeba już zawracać sobie tym głowy.

Konfiguracja pluginu w pom.xml

W moim wypadku wygląda tak:

            <plugin>
                <groupId>org.cloudfoundry</groupId>
                <artifactId>cf-maven-plugin</artifactId>
                <version>1.1.3</version>
                <configuration>
                    <server>mycloudfoundry-instance</server>
                    <org>namiekko</org>
                    <space>development</space>
                    <appname>szafbook</appname>
                    <target>http://api.run.pivotal.io</target>
                    <url>http://szafbook.cfapps.io/</url>
                    <memory>1024</memory>
                    <services>
                        <service>
                            <name>mLabMongoDB</name>
                            <label>mLabMongoDB</label>
                            <provider>mLab</provider>
                            <version>n/a</version>
                            <plan>sandbox</plan>
                        </service>
                    </services>
                </configuration>
            </plugin>

<groupId>org.cloudfoundry</groupId>

<artifactId>cf-maven-plugin</artifactId>

<server>mycloudfoundry-instance</server>

<org>namiekko</org>

<space>development</space>

<appname>szafbook</appname>

<target>http://api.run.pivotal.io</target>

<url>http://szafbook.cfapps.io/</url>

<name>mLabMongoDB</name>

<label>mLabMongoDB</label>

<plan>sandbox</plan>

</service>

</services>

</configuration>

</plugin>

Czym jest mycloudfoundry-instance? O tym poniżej.

Dane logowania

Dane logowania można podać w konsoli (ale wtedy nie będzie to wdrożenie za pomocą jednego polecenia!), w treści pom.xml (ale wtedy trafią one do systemu kontroli wersji, być może publicznego!), albo zdefiniować je w przeznaczonym dla Mavena pliku settings.xml na własnym dysku. Więcej o samym pliku settings.xml można poczytać tutaj. Szukać go należy (lub utworzyć) na jednej z dwóch ścieżek:

${maven.home}/conf/settings.xml (dla całej instalacji Mavena)
${user.home}/.m2/settings.xml (per użytkownik)

U mnie wpis wygląda tak:

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
  ...
  <servers>
     ...
	<server>
	  <id>mycloudfoundry-instance</id>
	  <username>justyna@...</username>
	  <password>...</password>
	</server>
  </servers>
  ...
</settings>

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">

...

...

<id>mycloudfoundry-instance</id>

<username>justyna@...</username>

</server>

</servers>

...

</settings>

id to nadana przeze mnie nazwa, za pomocą której mogę odwołać się do tej konfiguracji w pliku pom.xml (linia 6 w listingu z konfiguracją).

Więcej informacji

Więcej informacji na temat korzystania z pluginu można znaleźć na stronie https://docs.run.pivotal.io/buildpacks/java/build-tool-int.html.

Napotkane problemy

Wcześniej musiałam tylko raz wyklikać powiązanie pomiędzy aplikacją a usługą MongoDB (mLab). Przy wdrożeniach przez konsolę cf konfiguracja ta była zachowywana. Dlatego początkowo pominęłam definicję serwisów w konfiguracji pluginu (linie 13-21). Błąd! – baza danych była przez to “odczepiana” od aplikacji przy wdrożeniu.

Kod

Jak zwykle w GitHub.

PS.

Wiedziałam, że po zakończeniu konkursu Daj się poznać wrócę do swojego projektu, ale nie byłam pewna, czy chcę na ten temat blogować. Co mnie przekonało? To, że kiedy zapomniałam, jakie czynności należy wykonać w celu podłączenia bazy danych do aplikacji w chmurze, nie musiałam szukać daleko. Zerknęłam jedynie we własne wcześniejsze teksty! W ten sposób zostałam swoim najwdzięczniejszym czytelnikiem.

Mój zalążek projektu kompiluję i buduję przy użyciu Mavena. Maven (ang. “spec”) to narzędzie do budowania projektów napisanych w Javie. Sam Maven także został napisany w tym języku. Maven pozwala w uporządkowany sposób zarządzać zagadnieniami takimi jak: kompilacja, testowanie, budowanie, wynajdowanie i pobieranie zależności, generowanie dokumentacji.

Po co mi Maven, skoro mogę zbudować projekt w moim IDE? Po pierwsze, IDE nie zawsze jest pod ręką i może nagle okazać się, że na komputerze kolegi nie da się zbudować pilnie poprawionej wersji kodu, gdyż brakuje pięciu bibliotek (a po ich pobraniu – pięciu kolejnych, wymaganych przez te pierwsze). Po drugie, jeśli kod ma być testowany, a nawet wdrażany automatycznie, to przecież potrzebna jest możliwość uruchomienia go z zewnątrz. Po trzecie wreszcie – Maven to cała masa udogodnień i gotowych rozwiązań.

Konfigurację projektu mavenowego umieszcza się w pliku pom.xml. Plik ten można napisać samemu, ale najczęściej jest on generowany przez jakiś inicjalizator. W moim wypadku był to wspomniany już wcześniej Spring Initializr, ale najczęściej szablon generuje sam Maven w oparciu o żądany “archetyp”. Poniższe wywołanie stworzy szkielet aplikacji webowej z odpowiednio zainicjalizowanym plikiem pom.xml:

mvn archetype:create
  -DgroupId=[your project's group id]
  -DartifactId=[your project's artifact id]
  -DarchetypeArtifactId=maven-archetype-webapp

mvn archetype:create

-DgroupId=[your project's group id]

-DartifactId=[your project's artifact id]

-DarchetypeArtifactId=maven-archetype-webapp

Powstaje w ten sposób następująca struktura:

|-- src
|   `-- main
|       `-- java
|           |-- resources
|           |-- webapp
|           |   `-- WEB-INF
|           |       `-- web.xml
|           `-- index.jsp
`-- pom.xml

|-- src

| `-- main

| `-- java

| |-- resources

| |-- webapp

| | `-- WEB-INF

| | `-- web.xml

| `-- index.jsp

`-- pom.xml

Wygląda znajomo?

Plik pom.xml mojego projektu wygląda tak:

<?xml version="1.0" encoding="UTF-8"?>
<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>pl.namiekko</groupId>
	<artifactId>szafbook</artifactId>
	<version>0.0.1-SNAPSHOT</version>
	<packaging>jar</packaging>

	<name>szafbook</name>
	<description>Social Wardrobe Manager</description>

	<parent>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-parent</artifactId>
		<version>1.3.3.RELEASE</version>
		<relativePath /> <!-- lookup parent from repository -->
	</parent>

	<properties>
		<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
		<java.version>1.8</java.version>
	</properties>

	<dependencies>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-data-rest</artifactId>
		</dependency>
		...
	</dependencies>

	<build>
		<plugins>
			<plugin>
				<groupId>org.springframework.boot</groupId>
				<artifactId>spring-boot-maven-plugin</artifactId>
			</plugin>
		</plugins>
	</build>

</project>

<?xml version="1.0" encoding="UTF-8"?>

<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">

<groupId>pl.namiekko</groupId>

<artifactId>szafbook</artifactId>

<version>0.0.1-SNAPSHOT</version>

<name>szafbook</name>

<description>Social Wardrobe Manager</description>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-starter-parent</artifactId>

<version>1.3.3.RELEASE</version>

</parent>

<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

<java.version>1.8</java.version>

</properties>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-starter-data-rest</artifactId>

</dependency>

...

</dependencies>

<build>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-maven-plugin</artifactId>

</plugin>

</plugins>

</build>

</project>

Co oznaczają poszczególne elementy?

project: obowiązkowy znacznik najwyższego poziomu.
modelVersion: informacja o tym, z jakiego modelu DOM (Document Object Model) korzysta dany pom.xml. DOM w Mavenie zmienia się bardzo rzadko.
groupId: unikatowy identyfikator organizacji bądź grupy, która stworzyła projekt; najlepiej oparty o URL.
artifactId: nazwa głównego artefaktu generowanego przez projekt.
packaging: rodzaj wynikowego archiwum (e.g. JAR, WAR, EAR, etc.).
version: wersja powstałego artefaktu. SNAPSHOT oznacza wersję roboczą, do której się nie przywiązujemy.
name: wyświetlana (np. w dokumentacji) nazwa projektu.
description: krótki opis projektu
parent: (nieobowiązkowy) nadrzędny pom.xml, w którym zawarte są różne domyślne ustawienia projektu (np. kodowanie, konfiguracja pluginów).
properties: właściwości projektu. Ja podaję kodowanie źródeł oraz wersję Javy.
dependencies: zależności, czyli biblioteki potrzebne do zbudowania projektu. Jeśli nie ma ich na dysku, zostaną pobrane z repozytorium Mavena. Oprócz id grupy i artefaktu najczęściej trzeba podać także wersję, ale w tym wypadku wersjami podstawowych bibliotek zarządza wspomniany przed chwilą rodzic.
build: tu można zdefiniować podstawowe informacje na temat procesu budowania, np. lokalizację zasobów, profile budowania, niezbędne pluginy i ich konfiguracja. Pluginy w Mavenie mogą wszystko: potrafią przeprowadzić statyczną analizę kodu, przeformatować pliki itp. Moja aplikacja korzysta w tej chwili z pluginu Spring Boot Maven plugin, który umożliwia tworzenie uruchamialnych plików z aplikacją webową

Gdzie Maven przechowuje biblioteki?
Jeśli w systemie brakuje wymaganych bibliotek, Maven pobiera je ze zdalnego repozytorium http://mvnrepository.com lub innych wskazanych repozytoriówi umieszcza w repozytorium lokalnym.

Domyślna lokalizacja lokalnego repozytorium Mavena w systemie Windows

Oto najważniejsze standardowe polecenia Mavena (kolejność nie jest przypadkowa):

validate: sprawdź, czy projekt jest skonfigurowany w sposób umożliwiający jego zbudowanie.
compile: skompiluj kod, jeśli zmienił się od poprzedniego razu
test: przetestuj kod (testy jednostkowe, niewymagające wdrożenia).
package: w oparciu o skompilowany kod utwórz wynikowe archiwum (np. JAR czy WAR).
integration-test: przeprowadź testy integracyjne (może obejmować wdrożenie).
verify: sprawdź jakość wynikowego archiwum.
install: zainstaluj archiwum w lokalnym repozytorium Mavena. Projekt stanie się wówczas dostępny jako zależność dla innych projektów.
deploy: wdróż!
clean: usuń wszystkie artefakty wygenerowane przez poprzednie buildy.
site: wygeneruj dokumentację (HTML w oparciu o Javadoc).

Jak to wygląda w moim projekcie? W oparciu o pom.xml powstanie plik szafbook-0.0.1-SNAPSHOT.jar. Mogę go uruchomić w konsoli – zawiera wbudowany serwer Tomcata, na którym odpali się moja aplikacja.

mvn package
java -jar target/szafbook-0.0.1-SNAPSHOT.jar

1 2	mvn package java -jar target/szafbook-0.0.1-SNAPSHOT.jar

Mavena można podpiąć pod wszystkie najważniejsze IDE. W Eclipse będzie to wyglądało tak:

W kolejnym wpisie postaram się odpowiedzieć (sobie) na pytanie, czy w przypadku mojego projektu warto porzucić Mavena na rzecz coraz popularniejszego systemu budowania Gradle.

Bonus: troubleshooting. Gdzie mój pom.xml?! Eclipse domyślnie wyświetla pom.xml w postaci formularza. Poniższa ilustracja pokazuje, gdzie kliknąć, żeby dostać się do wersji tekstowej.

Na miękko

Archiwa tagu: Maven

Na co komu Maven?

Milsza strona programowania