1.Великі програми

Ми вже навчилися писати маленькі програми, тож тепер будемо вчитися писати великі. Як відомо, чим більша та складніша програма, тим більше за її розробку платять грошей:) Почнемо цю лекцію з невеличкої передісторії…

Зі збільшенням розміру програм розробники зіштовхнулися з двома новими обставинами:

  • Над однією програмою працює велика кількість людей.
  • Немає такої людини, яка б знала код всієї програми.

Регулярно почали виникати ситуації, коли програміст фіксив баг в одному місці програми і, одночасно, ламав щось в іншому. У release documentation навіть з'явився такий жарт:

Список змін:

  • Виправили старі баги:)
  • Додали нові:(

Тоді ж вигадали два підходи для вирішення цієї проблеми: технічний та менеджерський.

Технічний підхід полягав у тому, що програми розбивали на частини: бібліотеки та модулі. Кожен такий модуль був невеликою цеглиною, з якої потім вибудовувалися великі проєкти. Бібліотеки – це такі універсальні компоненти, які можуть використовуватися в різних програмах.

Менеджерський підхід був ще цікавішим: у ньому обмежували кількість людей, які можуть працювати над одним проєктом/бібліотекою. Емпірично навіть вивели правило: команда має бути такого розміру, щоб "її можна було нагодувати двома піцами". Зазвичай це означає, що якщо над проєктом працює понад 8 осіб, його потрібно розділити на два окремих проєкти.

У спільноті Java-розробників популярним стало написання бібліотек на всі випадки життя та викладання їх у спільний доступ. Таким чином, Java-програмісти мали змогу не писати знову той самий код (який часто виходив недосконалим і містив баги), а користуватися готовими і перевіреними рішеннями.

Додатковим стимулом стало те, що мова Java набула великої популярності при написанні серверних рішень (працювала на бекенді). По-перше, у серверного ПЗ вищі вимоги до надійності, і використання перевірених часом бібліотек завжди краще за написання свого коду.

По-друге, сервери практично не мають обмежень щодо розміру коду. Розробник мобільного застосунку намагається вмістити його в 10 мегабайт, десктопного застосунку – в 100 мегабайт. А бекенд-розробник на Java може додати до проєкту кілька десятків гігабайт бібліотек, і йому слова ніхто не скаже:)

Це, до речі, не жарт. Можна легко зустріти бекенд-проєкт із кількох десятків модулів та з парою сотень бібліотек. Ось тільки описувати (і змінювати!) сценарії збирання таких проєктів стало надзвичайно важко.

Аж ось з'явився Maven.

2. Знайомство з Maven

Maven – це спеціальний "фреймворк" для керування та складання програм. Він стандартизує 3 речі:
  • Опис проєкту;
  • Сценарії складання проєктів;
  • Залежність між бібліотеками.

Попередником Maven'а був Ant, а спадкоємцем є Gradle. Але саме Maven розвинув і довів до досконалості три зазначені стандарти, а також регламентував їхню взаємодію. Саме він вивів роботу Java-спільнот на новий рівень. Давай розглянемо його детальніше.

Maven'а

Технічно Maven – це спеціальна програма/сервіс, основна мета якої – керувати процесом складання проєктів. Її можна просто завантажити як архів та розпакувати у будь-яку директорію. Спеціальний інсталятор для цього не потрібен.

Графічного інтерфейсу в неї нема: всі команди віддаються за допомогою консолі. Щоб з нею було ще комфортніше працювати, рекомендується прописати у своїй ОС спеціальні змінні оточення (environment variables).

Також у Maven є спеціальний репозиторій (директорія/папка), де він зберігає бібліотеки, які використовує при складанні проєктів. Тобі потрібно буде обрати якусь папку на диску і призначити її як репозиторій.

Ще з цікавого можна відзначити наявність глобального Maven-репозиторію для всіх бібліотек, але про це розповімо трохи згодом.

3. Завантаження та встановлення Maven

У Maven є офіційний сайт maven.apache.org. Там дуже багато документації стосовно проєкту, тож якщо виникнуть труднощі чи додаткові питання – заходь, не соромся.

Також на сторінці downloads (https://maven.apache.org/download.cgi) можна завантажити архів з maven (apache-maven-3.8.5-bin.zip). Розпакований архів важить десь 10 Мб, хоча для локального maven репозиторію з часом буде потрібно кілька сотень мегабайт пам'яті.

Maven написаний на Java та вимагає JRE не нижче 7 версії, а також прописані змінні оточення типу JAVA_HOME.

Просто створи на комп'ютері папку Maven, наприклад, d:\devtools, і розпакуй до неї архів з Maven. У результаті у тебе має бути папка типу d:\devtools\maven\bin, де будуть знаходитися основні бінарні файли проєкту.

4. Змінні оточення

Після цього потрібно додати шлях до папки bin з розпакованого архіву до змінної середовища PATH.

Щоб встановити змінну середовища (environment variable) у Windows 10, потрібно перейти у Панель керування — Система — Додаткові параметри системи. Потім натиснути "Змінна середовища", знайти PATH та обрати "Змінити", після чого додати шлях d:\devtools\maven\bin у кінець рядка. Зверни увагу: шлях повинен вести саме до папки bin.

У ОС на основі Unix змінну середовища можна додати за допомогою консольної команди:


export PATH=/opt/apache-maven-3.8.5/bin:$PATH

Якщо все зроблено правильно, в консолі потрібно набрати команду: «mvn -v». У відповіді ти побачиш щось на кшталт:

<

C:\Users\Zapp>mvn -v
Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 15:51:28+0200)
Maven home: T:\apache-maven-3.0.5\bin\..
Java version: 1.8.0_65, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_65\jre
Default locale: en_US, platform encoding: Cp1251
OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"

5. Локальний репозиторій Maven

Також ти можеш призначити спеціальну папку, де Maven зберігатиме jar-бібліотеки, які він використовує під час складання проєктів. Таку папку називають локальний maven репозиторій.

Якщо не призначити таку папку, Maven створить її в домашній директорії поточного користувача. У мене це директорія: C:UsersZapp.m2

Папка має доволі специфічне ім'я “.m2”. Хоча користувачів Linux воно не лякає: там це досить поширений підхід до найменування різних ”репозиторіїв” та/або будь-якого іншого сховища службової інформації.

Важливо! Не розташовуй Maven у системних папках, тому що під час роботи йому знадобляться права на запис до цих папок, і це може викликати нездоровий інтерес з боку антивірусу або операційної системи.

Maven до версії 3.5 вимагав зазначити змінну оточення з ім'ям M2_HOME, але тепер це не потрібно.

Докладніше про конфігурування Maven можна прочитати за посиланням: https://maven.apache.org/configure.html