Чому мавен? Які переваги? [зачинено]


131

Які основні переваги використання maven порівняно з скажімо мурашкою? Здається, це більше роздратування, ніж корисний інструмент. Я використовую maven 2, з звичайним Eclipse Java EE (без m2eclipse) та tomcat.

Прихильники Мейвена вірять у це

  1. Maven дозволяє легко отримати залежність від пакета

  2. Maven змушує вас мати стандартну структуру каталогів

З мого досвіду

  1. З'ясувати залежність пакетів насправді не так складно. Ви все одно рідко це робите. Можливо, один раз під час налаштування проекту та ще декілька під час оновлення. З Maven ви в кінцевому підсумку виправляєте невідповідні залежності, погано написані poms і все одно робите виключення пакетів.

  2. Повільний цикл FIX-COMPILE-DEPLOY-DEBUG, що вбиває продуктивність. Це мій головний захват. Ви внесете зміни, вам доведеться чекати, коли Maven Build запустить, і чекати, коли він розгорнеться. Жодного гарячого розгортання.

Або я просто роблю це неправильно? Будь ласка, вкажіть мене в потрібному напрямку, я всі вуха.


1
Мене дуже цікавить точка 2. Хтось ще помічає повільний цикл виправлення-збирання-розгортання? або всі щось знають, але про це мовчать, оскільки Мейвен - це найкраще, що ми маємо / найпоширеніша / найкрутіша річ. Створення війни / вуха для розгортання досить погано, Maven робить це гірше. На моїй машині потрібно грубо 5 секунд, щоб переглянути jsp зміну на проект Maven, на зруйнованій структурі каталогів? менше 1 сек. Я можу зберегти кілька разів, і він збирає лише останню зміну на maven? кожне збереження запускає збірку.
trix

Можливо, maven тут не проблема, але підтримка / плагін IDE? Однак, maven вже довгий час, якщо ми не можемо це зробити правильно, чи варто рухатись / вигадувати / пропонувати щось інше? до того ж Ivy
trix

2
@Javid Незважаючи на те, що назва питання виглядає подібною, основна частина цього питання є іншою IMO, і я не вважаю це дуром.
Паскаль Thivent


На секунду пролунало так, ніби ви говорили про NuGet ...
micahhoover

Відповіді:


108

З'ясувати залежність пакетів насправді не так складно. Ви все одно рідко це робите. Можливо, один раз під час налаштування проекту та ще декілька під час оновлення. З Maven ви в кінцевому підсумку виправляєте невідповідні залежності, погано написані poms і все одно робите виключення пакетів.

Не так складно ... для іграшкових проектів. Але проектів, над якими я працюю, є багато, насправді багато, і я дуже радий їх перехідним шляхом, щоб мати для них стандартизовану схему імен. Ручне управління всім цим вручну було б кошмаром.

І так, іноді доводиться працювати над зближенням залежностей. Але подумайте про це двічі, це не притаманне Maven, це властиво будь-якій системі, що використовує залежності (і я взагалі тут кажу про залежності Java).

Тож з Ant потрібно виконувати ту саму роботу, за винятком того, що ви повинні робити все вручну: захопити певну версію проекту A та її залежностей, схопити якусь версію проекту B та її залежностей, зрозуміти, які саме версії вони використовують, перевіряючи що вони не перетинаються, перевіряючи, що вони несумісні тощо. Ласкаво просимо в пекло.

З іншого боку, Maven підтримує управління залежностями і отримає їх для мене транзитивно, і надає мені інструменти, необхідні для управління складністю, властивою для управління залежностями : я можу аналізувати дерево залежності, контролювати версії, які використовуються в перехідних залежностях, виключати деякі з їх, якщо потрібно, керуйте конвергентом через модулі тощо. Ніякої магії немає. Але принаймні у вас є підтримка.

І не забувайте, що управління залежністю - лише невелика частина того, що пропонує Мейвен, є набагато більше (навіть не згадуючи про інші інструменти, які добре інтегруються з Мейвен, наприклад, Sonar ).

Повільний цикл FIX-COMPILE-DEPLOY-DEBUG, що вбиває продуктивність. Це мій головний захват. Ви внесете зміни, вам доведеться чекати, коли Maven Build запустить, і чекати, коли він розгорнеться. Жодного гарячого розгортання.

По-перше, чому ви використовуєте Maven так? Я не. Я використовую свій IDE для написання тестів, коду до тих пір, поки вони не пройдуть, рефактор, розгортання, гаряче розгортання та запуск локальної збірки Maven, коли я закінчу, перш ніж зробити зобов’язання, щоб переконатися, що я не буду порушувати безперервне збирання.

По-друге, я не впевнений, що використання мурахи зробить все набагато краще. На мій досвід, модульні побудови Maven за допомогою бінарних залежностей дають мені швидший час побудови, ніж типові монолітні побудови Ant. У будь-якому разі, подивіться на Maven Shell, щоб готово (повторно) використовувати середовище Maven (що до речі дивовижно).

Отже, і, на жаль, вибачте, що насправді Maven не вбиває вашу продуктивність, це ви неправильно використовуєте свої інструменти. І якщо ви цим не задоволені, ну, що я можу сказати, не використовуйте. Особисто я використовую Maven з 2003 року і ніколи не оглядався.


@Pascal, чи можете ви сказати, якими інструментами ви користуєтесь? IDE, плагіни тощо. Ви говорите нам, що якщо я зміню файл .properties або jsp, це буде розгорнуто, не будуючи створення Maven? (можливо, гаряче розгортання тут не є правильним терміном). Мені не було зрозуміло, що я маю на увазі з мурашкою. Я мав на увазі використовувати стандартний каталог, що підірвався, під час розробки та використовувати мурашник для створення війни / вуха перед випуском. Для розгорнутого каталогу правила прості, копіюйте / компілюйте файли з src в класи та не торкайтеся решти.
trix

продовження ... Однак у моїх проектах те, що розгортається на tomcat, - це банки з модулями. Якщо я зміню .jsp, чи не доведеться переробляти ці банки?
trix

4
Ви повинні визнати, більшість проектів - це іграшкові проекти, які називають простими залежностями. Це просто закон статистики.
trix

2
@trix, щодо гарячого розгортання мураха проти Maven: якщо ви не робите збірки мурашок для гарячого розгортання, чому ви використовуєте Maven для того ж? Я думаю, якщо ти використовуєш мурашник для того ж, це займе принаймні стільки ж часу ... чи не так?
Редді

2
Отже, Паскаль, чи можете ви сказати нам, як у вас є проект, налаштований на природу Maven і не використовуєте процес збирання для розгортання? Це пункт 2 початкового питання. Мені цікаво, як це зробити, тому дуже вдячний, якщо ви зможете дати нам чітке пояснення.

20

Maven можна вважати повноцінним інструментом розробки проектів, а не просто інструментом побудови, як Ant. Вам слід використовувати ID Eclipse ID з плагіном Maven, щоб виправити всі ваші проблеми.

Ось кілька переваг Maven, цитовані з переваг використання сторінки Maven :

Геннінг

  • швидке налаштування проекту, ніяких складних файлів build.xml, просто POM та йдіть
  • всі розробники в проекті використовують однакові залежності від централізованої POM.
  • отримання кількості звітів та показників для проекту "безкоштовно"
  • зменшити розмір розподілу джерел, оскільки банки можна витягувати з центрального місця

Еммануель Веніссе

  • Доступно багато цілей, тому не потрібно розробляти якусь конкретну частину процесу збирання всупереч ANT, ми можемо повторно використовувати існуючі завдання ANT у процесі збирання за допомогою модуля antrun

Джессі Макконелл

  • Сприяє модульному дизайну коду. завдяки спрощенню управління проектами багатоточків, це дозволяє розробити дизайн у багатоплідні логічні частини, поєднуючи ці частини разом за допомогою відстеження залежності у файлах пом.
  • Застосовує модульну конструкцію коду. легко платити lipservice за модульний код, але коли код знаходиться в окремих проектах, що складаються, неможливо перекреслити запилення посилань між модулями коду, якщо ви спеціально не дозволите це в управлінні залежністю ... немає "я не буду" просто зробіть це зараз і виправте його пізніше.
  • Управління залежністю чітко задекларовано. за допомогою механізму управління залежністю ви повинні спробувати накрутити версію вашої банки ... немає жодної класичної проблеми "яка версія цього банку для постачальників це?" А налаштування його на існуючий проект зірває верхню частину існуючого безладу, якщо він існує, коли ви змушені робити "невідомі" версії у вашому сховищі, щоб почати працювати та працювати ... це або брехні собі, що ви знаєте фактична версія ABC.jar.
  • Сильний типовий життєвий цикл існує чіткий визначений життєвий цикл, що програмна система проходить від початку побудови до кінця ... і користувачам дозволено змішувати і співставляти свою систему з життєвим циклом, а не обробляти їх власним життєвим циклом. це має додаткову перевагу, що дозволяє людям переходити від одного проекту до іншого та говорити, використовуючи той самий словник з точки зору створення програмного забезпечення

Вінсент Массол

  • Більший імпульс: Мурашка тепер є спадщиною і не рухається швидко вперед. Maven просувається вперед швидко, і існує потенціал, що навколо Maven є багато високоцінних інструментів (CI, проект інформаційної панелі, інтеграція IDE тощо).

5
В той час як голосування за відмовою, вкажіть причину, це не інше, а етичне правило щодо стартового потоку.
ЙоК

1
З посиланнями немає нічого поганого, але вам дійсно потрібно зрозуміти, що вміст не ваш.
Паскаль Thivent

Дякую. Я переконуюсь, що я цитую його, окрім того, як просто зазначити, звідки воно посилалось. всього 30 непарних днів у стаковому потоці та ще вивчаю мистецтво :).
Йок

11

З'ясувати залежність для малих проектів не складно. Але як тільки ви почнете мати справу із деревом залежності із сотнями залежностей, речі можуть легко вийти з рук. (Я кажу з досвіду тут ...)

Інший момент полягає в тому, що якщо ви використовуєте IDE з інкрементальною компіляцією та підтримкою Maven (наприклад, Eclipse + m2eclipse), вам слід мати змогу налаштувати редагування / компілювання / гаряче розгортання та тестування.

Я особисто цього не роблю, тому що я прийшов з недовірою до цього способу розвитку через поганий досвід у минулому (до Мейвена). Можливо, хтось може прокоментувати, чи дійсно це працює з Eclipse + m2eclipse.


Можна почати з Maven, щоб отримати всі залежності, потім скопіювати залежності у свій проект, правда?
trix

2
Я гадаю, ти міг би. Але це може бути зламаним, якщо ви оновили залежність свого проекту ... або якщо ваш проект залежав від знімків.
Стівен С

Я маю на увазі два проекти, єдиною метою проекту є здобути залежність. Використовуйте керування версіями для відстеження змін між оновленнями залежностей. Я все одно це роблю, просто щоб я міг побачити зміни, якщо це порушить мою збірку.
trix

4
Тьфу. Це не так, як Maven призначений для використання. Однією з головних переваг Maven є уникання перевірки залежних бібліотек на контроль версій. Зі своїм підходом ви будете захаращувати свій VCS безліччю версій безлічі двійкових файлів. А деякі VCS особливо погано обробляють двійкові файли.
Стівен С

2
Як правило, ви навчитеся важкому способу бути дуже втомленим від будь-якої магії при написанні програм: -S
Thorbjørn Ravn Andersen

9

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

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

редагувати: Станом на 2016 рік Maven - єдиний інструмент побудови Java, де всі три основні ІДЕ можуть використовувати джерела з коробки. Іншими словами, використання maven робить ваш збір IDE-агностиком. Це дозволяє, наприклад, використовувати Netbeans профілювання, навіть якщо ви зазвичай працюєте в затемненні


1
І навпаки також справедливо, багато людей приходять до мавен з заздалегідь
задуманою

Протилежність? Ти маєш на увазі?
Thorbjørn Ravn Andersen

9

Переваг в порівнянні з мурахами досить багато. Я намагаюся їх узагальнити тут.

Конвенція про конфігурацію
Maven використовує відмінний підхід до розробки та запуску проекту, що дозволяє легко перейти до проекту. Зазвичай для отримання артефактів проекту потрібен лише рахунок і команда maven.

Модуляризація
проекту Конвенції проекту пропонують (або краще) примусити розробника модулювати проект. Замість монолітного проекту вас часто змушують розділити проект на більш дрібні підкомпоненти, що полегшує налагодження та керує загальною структурою проекту.

Управління залежністю та життєвий цикл проекту
Загалом, з хорошою конфігурацією SCM та внутрішнім сховищем, управління залежністю є досить простим, і ви знову змушені думати з точки зору життєвого циклу проекту - компонентних версій, управління випуском тощо. Трохи складніший за мурашник щось, але знову ж таки покращення якості проекту.

Що не так з Maven?
Мейвен непростий. Цикл складання (що робиться і коли) не є настільки чітким в межах POM. Крім того, деякі проблеми виникають з якістю компонентів та відсутніми залежностями у публічних сховищах.
Найкращим підходом (для мене) є наявність внутрішнього сховища для кешування (і збереження) залежностей навколо, а також застосувати для управління випуском компонентів. За проекти, що перевищують зразки проектів у книзі, ви подякуєте Maven до чи після


6

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


3

Maven - це потужний інструмент управління проектами, який базується на POM (модель об’єкта проекту). Він використовується для побудови проектів, залежності та документації. Це спрощує процес збирання, як ANT. Але це занадто багато просунутого, ніж ANT. Maven допомагає керувати - збирання, документація, звітування, SCM, випуски, розповсюдження. - maven сховище - це каталог запакованого файлу JAR з файлом pom.xml. Maven здійснює пошук залежностей у сховищах.


2

Я ніколи не стикався з точкою 2? Чи можете ви пояснити, чому ви думаєте, що це впливає на розгортання будь-яким чином. Якщо що-небудь maven дозволяє структурувати свої проекти модульно, що фактично дозволяє виправляти помилки в певному рівні, а також дозволяє незалежну розробку API з решти проекту, наприклад.

Цілком можливо, що ви намагаєтеся зв'язати все в єдиний модуль, і в цьому випадку проблема насправді не справжня, а спосіб, яким ви користуєтесь.


Я використовую звичайний джип eclipse, maven 2 та tomcat. Очевидно, веб-додаток. Якщо я змінюю файл властивостей або jsp, щоб побачити мої зміни на tomcat, maven повинен виконати його збірку, створити війну / вухо та розгорнути до tomcat. Це повільно порівняно з тим, якщо я використовую структуру каталогів, що підірвалася.
trix

1
@trix Hot розгортання в Eclipse з Tomcat просто працює. Ви робите це неправильно.
Паскаль Thivent

0

Це повинен був бути коментарем, але він не відповідав довжині коментарів, тому я опублікував це як відповідь.

Всі переваги, згадані в інших відповідях, досягаються більш простими способами, ніж використання maven. Якщо, наприклад, ви новачок у проекті, ви все одно витратите більше часу на створення архітектури проекту, приєднання до компонентів, кодування, ніж завантаження банок та копіювання їх у папку lib. Якщо у вас є досвід у вашому домені, то ви вже знаєте, як розпочати проект з яких бібліотек. Я не бачу ніякої користі від використання maven, особливо коли це створює багато проблем при автоматичному виконанні "управління залежностями".

У мене є лише знання про Maven середнього рівня, але я вам кажу, я робив великі проекти (як ERP), не використовуючи maven.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.