1.Великі програми
Ми вже навчилися писати маленькі програми, тож тепер будемо вчитися писати великі. Як відомо, чим більша та складніша програма, тим більше за її розробку платять грошей:) Почнемо цю лекцію з невеличкої передісторії…
Зі збільшенням розміру програм розробники зіштовхнулися з двома новими обставинами:
- Над однією програмою працює велика кількість людей.
- Немає такої людини, яка б знала код всієї програми.
Регулярно почали виникати ситуації, коли програміст фіксив баг в одному місці програми і, одночасно, ламав щось в іншому. У release documentation навіть з'явився такий жарт:
Список змін:
- Виправили старі баги:)
- Додали нові:(
Тоді ж вигадали два підходи для вирішення цієї проблеми: технічний та менеджерський.
Технічний підхід полягав у тому, що програми розбивали на частини: бібліотеки та модулі. Кожен такий модуль був невеликою цеглиною, з якої потім вибудовувалися великі проєкти. Бібліотеки – це такі універсальні компоненти, які можуть використовуватися в різних програмах.
Менеджерський підхід був ще цікавішим: у ньому обмежували кількість людей, які можуть працювати над одним проєктом/бібліотекою. Емпірично навіть вивели правило: команда має бути такого розміру, щоб "її можна було нагодувати двома піцами". Зазвичай це означає, що якщо над проєктом працює понад 8 осіб, його потрібно розділити на два окремих проєкти.
У спільноті Java-розробників популярним стало написання бібліотек на всі випадки життя та викладання їх у спільний доступ. Таким чином, Java-програмісти мали змогу не писати знову той самий код (який часто виходив недосконалим і містив баги), а користуватися готовими і перевіреними рішеннями.
Додатковим стимулом стало те, що мова Java набула великої популярності при написанні серверних рішень (працювала на бекенді). По-перше, у серверного ПЗ вищі вимоги до надійності, і використання перевірених часом бібліотек завжди краще за написання свого коду.
По-друге, сервери практично не мають обмежень щодо розміру коду. Розробник мобільного застосунку намагається вмістити його в 10 мегабайт, десктопного застосунку – в 100 мегабайт. А бекенд-розробник на Java може додати до проєкту кілька десятків гігабайт бібліотек, і йому слова ніхто не скаже:)
Це, до речі, не жарт. Можна легко зустріти бекенд-проєкт із кількох десятків модулів та з парою сотень бібліотек. Ось тільки описувати (і змінювати!) сценарії збирання таких проєктів стало надзвичайно важко.
Аж ось з'явився Maven.
2. Знайомство з Maven
Maven – це спеціальний "фреймворк" для керування та складання програм. Він стандартизує 3 речі:- Опис проєкту;
- Сценарії складання проєктів;
- Залежність між бібліотеками.
Попередником Maven'а був Ant, а спадкоємцем є Gradle. Але саме Maven розвинув і довів до досконалості три зазначені стандарти, а також регламентував їхню взаємодію. Саме він вивів роботу Java-спільнот на новий рівень. Давай розглянемо його детальніше.
Технічно 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