Чому у Мейвена такий поганий представник? [зачинено]

В Інтернеті багато розмов про те, як Мевен погано. Я використовую деякі функції Maven вже кілька років, і найголовніша перевага на мою думку - це управління залежністю.

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

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

ПРИМІТКА. Це не спроба викликати аргумент. Це спроба очистити FUD.

Я заглянув у мавен близько півроку тому. Ми починали новий проект, і не мали наслідок його підтримати. Це сказав:

• Мейвен - це все-нічого. Або принаймні, наскільки я міг сказати з документації. Ви не можете легко використовувати maven в якості заміни мурашника і поступово застосовувати більш досконалі функції.
• Згідно з документацією, Мейвен - це трансцендентне щастя, яке змушує здійснити всі ваші найсмішніші мрії. Вам просто потрібно роздумувати над посібником протягом 10 років, перш ніж стати освіченим.
• Maven робить ваш процес збирання залежним від вашого мережевого з'єднання.
• Maven має марні повідомлення про помилки. Порівняйте мурашник "Target x не існує в проекті y" з mvn "Недійсне завдання" запустіть ": ви повинні вказати дійсну фазу життєвого циклу або ціль у форматі plugin: goal або pluginGroupId: pluginArtifactId: pluginVersion: target" Корисно, він пропонує я запустити mvn з -e для отримання додаткової інформації, а це означає, що він буде надрукувати те саме повідомлення, а потім слід стека для BuildFailureException.

Значну частину моєї неприязні до Maven можна пояснити наступним уривком з Better Builds з Maven:

Коли хтось хоче знати, що таке Мейвен, вони зазвичай запитують "Що саме таке Мейвен?", І вони очікують короткої, звукозахисної відповіді. "Ну це інструмент побудови або сценарій рамки". Мейвен - це більше, ніж три нудні, не надихаючі слова. Це поєднання ідей, стандартів та програмного забезпечення, і неможливо перекрити визначення Maven просто перетравленими звуковими укусами. Революційні ідеї часто важко передати словами.

Моя пропозиція: якщо ви не можете передати ідеї словами, не слід намагатися написати книгу на цю тему, тому що я не збираюся телепатично поглинати ідеї.

• Це накладає на вас жорстку структуру з самого початку.
• Це на основі XML, тому читати так само важко, як і ANT.
• Повідомлення про помилки незрозуміле, і ви залишаєте себе на межі, коли справи йдуть не так.
• Документація погана.
• Це робить важкі речі легкими, а прості речі важкими.
• Це потребує занадто багато часу, щоб підтримувати середовище побудови Maven, що перешкоджає існуванню всеспівної системи збирання.
• Вимагає багато часу, щоб зрозуміти, що ви знайшли помилку в Maven і не налаштували щось не так. А помилки є і в дивних місцях.
• Це багато обіцяє, але зраджує тебе, як прекрасного і спокусливого, але емоційно холодного і маніпулятивного коханця.

У минулому я, звичайно, кусався і стогнав про Мавен . Але тепер я не був би без цього. Я відчуваю, що переваги значно переважають будь-які проблеми. Головним чином:

• Стандартизована структура проекту.
  • З огляду на те, що новий розробник приєднався до проекту:
    • Коли ви кажете, що це проект Maven, розробник знає макет проекту та як створити та упакувати проект
    • Коли ви скажете, що це проект Ant, тоді розробнику доведеться чекати, коли ви поясніть більше, або вам доведеться пройти через build.xml, щоб розібратися з речами.
  • Звичайно, завжди можна нав'язувати стандарт Ant для компанії, але я думаю, що частіше за все ви будете винаходити прислів’я.
• Управління залежністю.
  • Не тільки із зовнішніми бібліотеками, але й із внутрішніми бібліотеками / модулями. Обов’язково використовуйте проксі-сервер сховища Maven, наприклад Nexus або Artifactory .
  • Можна щось із цього зробити з Айві . Насправді, якщо все, що вам потрібно, це управління залежністю, вам, мабуть, краще використовувати Ivy.
• Особливо в рамках проекту. Я вважаю цілком корисним виривати невеликі підпроекти, і Maven добре справляється з цим. З мурашниками набагато складніше.
• Стандартизоване управління артефактами (особливо в поєднанні з зв'язком або артефактом) )
• Плагін випуску чудовий.
• Інтеграція Eclipse & NetBeans є досить хорошою.
• Інтеграція з Гудзоном чудова. Особливо графіки тренду для таких речей, як Findbugs.
• Це незначний момент, але той факт, що Maven вбудовує такі деталі, як номер версії всередині jar або war (не лише у назві файлу) за замовчуванням, надзвичайно корисний.

Мінуси для мене головним чином:

• Командний рядок є зовсім не корисним. Це почало мене дуже багато для початку.
• Формат XML дуже багатослівний. Я бачу, чому це було зроблено саме так, але читати все-таки боліло.
  • Однак це має XSD для легкого редагування в IDE.
• На початку важко обвести голову. Такі речі, як життєвий цикл, наприклад.
  • Однак, остаточне керівництво Maven є хорошим вступом.

Я справді вірю, що варто витратити трохи часу на знайомство з Мавен.

Мій практичний досвід двох великих проектів полягає в тому, що ми витратили 1000 - 1500 годин на кожен проект на проблеми, пов'язані з Maven, за винятком 500-годинного зусилля, щоб перейти від Maven 1 до Maven 2.

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

Інтеграція Eclipse - жахлива. (У нас виникли нескінченні проблеми з генерацією коду, наприклад, коли eclipse вийшов із синхронізації з генерованим кодом, і вимагає повного відновлення, досить часто. Виною є і maven, і затемнення, але eclipse корисніше, ніж maven і кажуть emacs, так затемнення залишається і Maven повинні йти.)

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

Структура проекту Mavens насправді не підходить для розробки Eclipse, і час збірки в затемненні збільшується.

Внаслідок проблеми з генерацією коду та синхронізації нам довелося досить часто перебудовуватися з scrach, скорочуючи свій код / ​​компілювати / тестовий цикл до нескінченного циклу компіляції / websurf / sleep / die / code, відсилаючи вас прямо до 90-х 40 хвилин складання.

Єдиним приводом для Maven є дозвіл на залежність, але я хотів би зробити це раз у раз, а не в кожній збірці.

Підводячи підсумок, maven настільки далекий від KISS, як це може бути. А також, адвокати, як правило, є типом людей, які святкують додатково у свій день народження, коли їхній вік є основним числом. Сміливо проголосуйте мене :-)

Мейвен чудовий. На мою думку, причина його репутації пов'язана з крутою кривою навчання. (що я нарешті близький до подолання)

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

Тому що Мейвен - це пристрій для зменшення дорослих чоловіків до ридання мас абсолютного терору.

Плюси:

• Управління залежністю. Вже кілька років я та мої колеги не завантажуємо та керуємо залежностями вручну. Це величезна економія часу.
• IDE-незалежність. Виявляється, всі основні IDE, Eclipse, IDEA та NetBeans мають гідну підтримку проектів Maven, щоб наші розробники не були зафіксовані в одному конкретному IDE.
• Командний рядок. У Maven підтримка одночасних конфігурацій IDE та командного рядка є простою, що добре для постійної інтеграції.

Мінуси:

• Доводиться вкладати гроші в навчання Мейвена. Ну, повинні це зробити. Хороша новина, не всі в колективі мають вчитися.
• Документація. Раніше це було проблемою, а тепер завдяки Сонатипу та їхній книзі ( http://www.sonatype.com/products/maven/documentation/book-defguide ) ситуація набагато краща.
• Жорсткість. Іноді складно і страшно робити речі так, як ти хочеш. Моя порада полягала б у тому, щоб не боротись і змушувати Мейвена робити те, що робить найкраще, прямо будує, або коли є стабільний моджо. В інших випадках ми випадаємо і робимо завдання або з завданнями Ant ( http://maven.apache.org/plugins/maven-antrun-plugin/ ) зовнішніми програмами. Мій особистий фаворит - Groovy plugun ( http://groovy.codehaus.org/GMaven ).

Конкуренція:

• Мураха: не має управління залежністю. Період.
• Плющ: все ще менш зрілий, ніж Мейвен (не те, що в останнього теж немає своїх причуд). Майже той самий набір функцій, тому немає переконливої ​​причини рухатися. Я зробив кілька спроб спробувати це; всі невдалі.

Підсумок: усі наші проекти вже кілька років здійснюються з Maven.

Я думаю, що це погана репутація у людей, які мають найпростіші та найскладніші проекти.

Якщо ви будуєте одну ВІР з однієї бази коду, це змушує вас переміщати структуру проекту та вручну перелічувати дві з трьох банок у файл POM.

Якщо ви будуєте один EAR з набору дев'яти прототипів файлів EAR з деякою комбінацією з п'яти файлів WAR, трьох EJB та 17 інших інструментів, банок та конфігурацій залежностей, які потребують підключення файлів MANIFEST.MF та XML у існуючі ресурси під час остаточної збірки; то Мейвен, ймовірно, занадто обмежує. Такий проект стає безладом складних вкладених профілів, файлів властивостей та неправильного використання цілей Maven build та позначення Classifier.

Тож якщо ви знаходитесь в нижній частині 10% від кривої складності, її надмірність. На верхніх 10% цієї кривої ви знаходитесь в жакеті.

Зростання Мейвена полягає в тому, що він добре працює на середину 80%

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

Мій досвід полягає в тому, що будь-яка проблема з Maven швидко переростає в багатогодинний постріл на сніп через павутини вкладених XML-файлів, як досвід, подібний до кореневого каналу.

Я також працював у магазинах, які сильно покладалися на Мейвена, люди, яким це сподобалось (кому сподобалось за аспект "натиснути кнопку, все це зробити") не зрозуміли цього. У складі Maven було мільйон автоматичних цілей, що, я впевнений, було б корисно, якби я відчував, що хотів би провести години, щоб прочитати, що вони зробили. Краще 2 цілі, які працюють, які ви повністю розумієте.

застереження: востаннє працював з Мейвен 2 роки тому, може бути, краще зараз.

Як і Гленн, я не думаю, що Мейвен має поганий представник, але змішаний представник. Я працюю 6 місяців виключно, намагаючись перенести досить великий проект-проект до Maven, і це чітко показує межі цього інструменту.

З мого досвіду, Мейвен добре підходить для:

• управління зовнішньою залежністю
• централізоване управління збіркою (пом. спадкування)
• багато плагінів для багатьох речей
• дуже хороша інтеграція з інструментами безперервної інтеграції
• дуже хороші можливості звітування (FindBugs, PMD, Checkstyle, Javadoc, ...)

І це має деякі проблеми з:

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

Щоб дати певний контекст, над цим проектом працює близько 30 розробників, і проект існує вже більше 5 років, тож: багато спадщини, багато вже створених процесів, багато спеціальних фірмових інструментів вже є. Ми вирішили спробувати переїхати до Maven, оскільки витрати на підтримку наших власних інструментів надто високі.

Я хотів би протиставити кілька скарг на цьому форумі:

Мейвен - це все-нічого. Або принаймні, наскільки я міг сказати з документації. Ви не можете легко використовувати maven в якості заміни мурашника і поступово застосовувати більш досконалі функції.

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

<?xml version="1.0" encoding="UTF-8"?>
<project name="foo" basedir="." xmlns:maven="antlib:org.apache.maven.artifact.ant" >
  <maven:dependencies verbose="true" pathId="maven.classpath">
    <maven:pom id="maven.pom" file="pom.xml" />
  </maven:dependencies>
</project>

Тепер у вас є об'єкт classpath з назвою 'maven.classpath', який містить усі основні залежності, визначені у файлі pom. Все, що вам потрібно, - це помістити банку з завданнями мурашки в каталог ваших мурашок.

Maven робить ваш процес збирання залежним від вашого мережевого з'єднання.

Процедура залежності та завантаження плагінів за замовчуванням залежить від підключення до мережі, так, але лише для початкової збірки (або якщо ви змінюєте залежність або плагіни, що використовуються). Після цього всі банки локально кешуються. І якщо ви хочете застосувати безмережеве з'єднання, ви можете сказати maven використовувати режим офлайн.

Це накладає на вас жорстку структуру з самого початку.

Не зрозуміло, чи йдеться про формат файлу або проблему "конвенція проти конфігурації". Для останнього існує дуже багато невидимих ​​за замовчуванням, таких як очікуване розташування вихідних файлів і ресурсів Java або сумісність джерела. Але це не жорсткість, це введення для вас значущих значень за замовчуванням, тому вам не потрібно їх чітко визначати. Усі налаштування можна легко замінити (хоча для початківця в документації важко знайти, як змінити певні речі).

Якщо ви говорите про формат файлу, це добре висвітлено у відповіді на наступну частину ...

Це на основі XML, тому читати так само важко, як і ANT.

По-перше, я не бачу, як можна поскаржитися на те, що якийсь аспект чогось "Не кращого за мурашник" як виправдання тому, що він має погану відповідь. По-друге, поки це ще XML, формат XML значно більш визначений. Крім того, оскільки його так визначено, набагато простіше зробити розумний товстий клієнт-редактор для POM. Я бачив сторінки, як довгі мурашки створюють сценарії, які стрибають всюди. Будь-який редактор сценаріїв для створення мурашок не збирається зробити це більш приємним, а лише черговим довгим списком взаємопов’язаних завдань, представлених дещо по-іншому.

Сказавши, що я бачив кілька скарг, які я бачив тут, які мають чи мають певну валідність, найбільша істота

• Документація погана / відсутня
• Відтворювані склади
• Інтеграція затемнення погана
• Клопи

На що моя відповідь двояка. По-перше, Maven - це набагато молодший інструмент, ніж Ant або Make, тому вам доведеться сподіватися, що для досягнення рівня зрілості цих програм знадобиться час. По-друге, добре, якщо вам це не подобається, виправте це . Його проект з відкритим кодом та його використання, а потім скарги на щось, на що кожен може допомогти у вирішенні, здається мені досить асиніним. Вам не подобається документація? Сприяйте цьому, щоб зробити його зрозумілішим, повнішим або доступнішим для початківця.

Проблема, що відтворюється, розбивається на два випуски, діапазон версій та автоматичне оновлення додатків Maven. Що стосується плагіну, у тому числі, якщо ви не переконуєтесь, що при повторному відновленні проекту через рік ви користуєтеся точно такою ж JDK та точно такою ж версією Ant, то це просто та сама проблема з іншою назвою. Для діапазонів версій я рекомендую працювати над плагіном, який створить тимчасовий пом із заблокованими версіями для всіх прямих та перехідних залежностей та зробить його частиною життєвого циклу випуску Maven. Таким чином, ваш poms build poms - це завжди точний опис усіх залежностей.

Він заслуговує на репутацію, яку він придбав. Не всім потрібна жорстка структура, на яку розробники Maven вважали, що підходить для кожного окремого проекту. Це так негнучко. І що для багатьох людей "Pro" - це управління залежністю, це IMHO - його найбільший "con". Мені абсолютно не подобається, коли Maven завантажує банки з мережі і втрачає сон через несумісність (так, офлайн режим існує, але чому я повинен мати усі ці сотні xml-файлів і контрольних сум). Я вирішую, які бібліотеки я використовую, і багато проектів мають серйозні занепокоєння щодо збірок, залежних від мережевого з'єднання.

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

Через рік я хотів оновити це: більше не маю такої думки щодо громади Мейвен. Я б не написав цієї відповіді, якби сьогодні було задано питання. Я збираюся додати свою сьогоднішню думку як окрему відповідь.

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

Мені подобається Мейвен, і мені це більше подобається, чим більше я його знаю. Однак одне, що впливає на мої почуття щодо цього: громада Maven в основному зосереджена навколо Sonatype ("компанія Maven"; саме там працюють багато хончов Maven), і Sonatype досить наполегливо штовхає свої корпоративні продукти на громаду.

Приклад: Потік щебетання "Maven Book" посилається на передбачуване вступ до управління сховищами .

Вибачте, але це "вступ" - це напівінформація, наполовину крок продажів для Nexus. Поп-вікторина: чи є інші менеджери репо, окрім Nexus та Nexus Pro? Крім того, що це має відношення до нібито відкритої книги Maven Book? О, так, розділ про управління сховищами було викладено в окрему книгу ... про Nexus. Ага. Якщо я вношу внесок у книгу Maven, чи отримую я плату за реферали, якщо я спричиняю збільшення продажів Nexus?

Уявіть собі, якби ви брали участь у форумі з розробки Java, і було зрозуміло, що співробітники Sun, які обговорювали Java, скористаються всіма можливими можливостями поговорити про NetBeans та "NetBeans Pro". Через деякий час вона втрачає частину свого почуття громади. Я ніколи не мав такого досвіду з Мурашкою.

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

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

Занадто багато магії.

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

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

• ненадійні віддалені сховища;
• залежність від плагінів і бібліотек з версіями SNAPSHOT або без версій.

Порівнюйте це з мурашиною збіркою, яка - хоча багатослівна та стомлена ІМО - працює, оскільки всі банки перевіряються на місцевому рівні.

Хороша частина полягає в тому, що проблеми вирішуються:

• використовуйте власне сховище Maven, яке стало просто, я використовую Archiva з хорошими результатами;
• завжди правильно версіюйте свої залежності. Maven почав блокувати версії плагінів у супер-POM, починаючи з 2.0.8 або 2.0.9, і всі ваші залежності повинні бути на випущених версіях.

відмінна ідея - погана реалізація.

Нещодавно я переїхав проект з Мурахи до Мейвена. На завершення це спрацювало добре, але мені довелося використовувати дві різні версії плагіна maven-Assembly-plugin та maven-jar-plugin в одному пом’їку (отримав два профілі), оскільки те, що працювало в одній версії, було порушено в іншому.

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

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

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

з повагою

v.

Мені подобається maven. Я використовував його з попереднього 1,0. Це потужний інструмент, який на балансі заощадив мені значну кількість часу та покращив мою інфраструктуру розвитку. Але я можу зрозуміти розчарування у деяких людей. Я бачу 3 види фрустрації:

1. де причини викликають реальну стурбованість (наприклад, багатослівні УЗО, відсутність документації),
2. деякі - це дезінформація (наприклад, "ви повинні мати підключення до Інтернету, щоб будувати" - неправда - цього немає, цього можна уникнути),
3. Деякі з них вивітрені в Maven, але насправді хтось інший винен ("не стріляй в месенджера").

У першому випадку реальні проблеми - ну, звичайно, є проблеми, POMs багатослівні, документація може бути кращою. Однак, незважаючи на це, можна швидко отримати хороший результат з Maven. Я штовхаю щоразу, коли отримую проект, побудований з мурашниками, і намагаюся імпортувати це у свій IDE. Налаштування структури каталогів може зайняти багато часу. з maven, це лише випадок відкриття файлу POM в IDE.

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

В останньому моменті, я вважаю, що захоплення перехідних залежностей Мейвена - це, мабуть, найвідоміший приклад.

Перехідні залежності - це природа реального програмного забезпечення, яке використовує повторне використання. DLL-пакети Windows, пакети Debian, пакети Java, пакети OSGi, навіть файл заголовка C ++ включає всі залежності і страждають від проблеми залежності. Якщо у вас дві залежності, і кожна використовує іншу версію одного і того ж, тоді вам доведеться якось вирішити це. Мейвен не намагається вирішити проблему залежності, а навпаки, виводить її на перший план і надає інструменти, що допомагають керувати проблемою, наприклад, повідомляючи про конфлікти та забезпечуючи послідовні залежності для ієрархії проектів, і фактично забезпечує абсолютний контроль над залежність проекту.

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

Мейвен не є причиною проблеми залежності, але робить її більш помітною. У вирішенні проблем залежності maven робить будь-яку залежність "виправленням" явним (зміна вашого POM, що перевершує залежність), а не неявною, як це має місце з банками, керованими вручну в контролі версій, де банки просто присутні, без нічого Підтримка погоди вони правильна залежність чи ні.

Я вважаю, що Maven має поганий представник, тому що більшість зловмисників не спостерігали комбінації Maven + Hudson + Sonar . Якби вони мали, вони запитували б "як мені почати"?

Деякі мої домашні улюбленці з Maven:

• Визначення XML є надзвичайно незграбним та багатослівним. Вони ніколи не чули про атрибути?

• У конфігурації за замовчуванням вона завжди обчислює мережу для кожної операції. Незалежно від того, корисно це ні для чого, виглядає надзвичайно нерозумно, потрібен доступ в Інтернет для "чистого".

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

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

• Ще одне рішення - встановити власний сервер "управління джерелом" для залежностей. Сюрприз: Більшість проектів вже мають контроль над джерелами, тільки це працює без додаткових налаштувань!

• Будівництво Maven неймовірно повільне. Поєднання з мережевими оновленнями це полегшує, але створення Maven все ще відбувається повільно. І жахливо багатослівний.

• Плагін Maven (M2Eclipse) інтегрується в Eclipse. Eclipse інтегрується досить чітко з програмним забезпеченням для управління версіями та з Ant. Інтеграція Maven дуже незграбна та потворна порівняно. Я згадував повільний?

• Мейвен продовжує буяти. Повідомлення про помилки не є корисними. Занадто багато розробників страждають від цього.

Гарне питання. Я щойно розпочав великий проект, і частина попередніх проектів полягала в тому, щоб запровадити модульність до нашої кодової бази.

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

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

Мураш багато використовують у ці дні, і я це люблю. Враховуючи це, я натрапив на маловідомого менеджера залежностей під назвою Apache Ivy . Плющ дуже добре інтегрується в Мураха і швидко та легко отримати основні налаштування пошуку JAR. Ще одна перевага Ivy полягає в тому, що він дуже потужний, але досить прозорий; ви можете перенести збірки за допомогою таких механізмів, як scp або ssh, досить легко; Пошук "ланцюгової" залежності від файлових систем або віддалених сховищ (сумісність Maven repo - одна з його популярних особливостей).

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

Я збираюся переглянути Apache Ivy в якийсь момент під час цього проекту, і я сподіваюся, що він буде працювати належним чином. Одне, що він зробив, - це дозволити нам, як команда, розробити, від яких бібліотек ми залежні, та отримати документально підтверджений список.

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

Наступні ресурси, що стосуються Ivy, можуть бути корисними:

• Порівняння Apache Ivy vs Maven 2 порівняння
• Apache Ivy FAQ
• Список функцій Apache Ivy

Я люблю Мейвен - це підвищує продуктивність, і я дуже радий, що більше не використовую мурашок (феу!)

Але якби я міг щось змінити, це було б:

1. Зробити pom.xmlфайл менш багатослівним
2. Зробіть полегшення включення .jars не зі сховища.

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

Використовувати Maven у простих проектах дуже просто, при більш великих / складних потрібні більші знання та глибше розуміння філософії Maven - можливо, на рівні компанії посада для гуру Maven, як адміністратора мережі. Основним джерелом висловлювань ненависті Мевена часто є незнання .

Ще одна нігтя для Мейвена - це відсутність гнучкості, як, наприклад, у Ant. Але пам'ятайте, що Мейвен має ряд умовностей - дотримуватися їх, здається, спочатку важко, але врешті-решт, часто рятуйте від проблем.

Нинішній успіх Мейвена доводить його цінність. Звичайно, ніхто не ідеальний, і Мейвен має свої мінуси і свої химерності, але, на мою думку, Мейвен повільно хилить своїх опонентів.

Я б не сказав, що у нього поганий представник настільки, як у нього змішаний представник. Якщо ваш проект дотримується парадигми "конвенція щодо конфігурації", яку підтримує Мейвен, то ви можете отримати багато важелів від нього. Якщо ваш проект не вписується добре у світогляд Мавена, то це може стати тягарем.

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

Для мене є стільки плюсів, скільки є мінусів щодо використання Maven vs Ant для внутрішніх проектів. Щодо проектів з відкритим кодом, я думаю, що Мейвен справив великий вплив на те, щоб зробити багато проектів набагато простішими. Не так давно минуло кілька годин, щоб середній проект OSS Java (на основі мурашок) був складений, маючи встановити тону змінних, завантажити залежні проекти тощо.

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

Якщо ви збираєтесь робити ставку на свій бізнес чи роботу на проект розвитку, ви хочете контролювати основи, тобто систему побудови. З Мейвен ви не контролюєте. Це декларативне та непрозоре. Розробники maven-Framework не мають уявлення про те, як створити прозору або інтуїтивно зрозумілу систему, і це зрозуміло з результатів журналу та документації.

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

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

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

Нещодавно я намагався повернути старий проект GWT / Maven / Eclipse до життя і 2 тижні всього вільного часу пізніше, я все ще не можу змусити його будувати послідовно. Час скоротити мої втрати і розвиватися, використовуючи мурашник / затемнення, на який я думаю ...

Коротка відповідь: Мені було дуже важко підтримувати систему побудови Maven, і я хотів би перейти до Gradle, як тільки можу.

Я працюю з Мейвен понад чотири роки. Я б назвав себе експертом з побудови систем, тому що в останніх (принаймні) п'яти компаніях, в яких я був, я робив капітальні реконструкції інфраструктури побудови / розгортання.

Деякі уроки, які я засвоїв:

• Більшість розробників, як правило, не витрачають багато часу на роздуми про побудову систем; як результат, збірка перетворюється на спагеті безлад хаків, але вони це цінують, коли цей безлад очищають та раціоналізують.
• Що стосується складності, я б скоріше мав прозору систему, яка викриває складність (як Мураха), ніж та, яка намагається зробити складні речі простими шляхом встановлення жорстких обмежень, як Мевен. Подумайте про Linux проти Windows.
• Maven має багато дір у функціональності, які потребують візантійських шляхів обходу. Це призводить до незрозумілих та незрозумілих файлів POM.
• Мураха є надзвичайно гнучким і зрозумілим, але файли мурашок теж можуть бути досить великими, оскільки це настільки низький рівень.
• Для будь-якого значного проекту розробники повинні створити власну структуру побудови / розгортання поза межами того, що надає інструмент; придатність структури до проекту має багато спільного з тим, наскільки легко підтримувати. Найкращі інструменти підтримають вас у створенні структури, а не борються з вами.

Я трохи заглянув у Gradle, і, схоже, він має потенціал бути кращим з обох світів, що дозволяє поєднувати опис декларативної та процедурної побудови.

Це складніше, ніж мова, якою ви писали свій проект. Налаштувати його правильно важче, ніж власне програмування.

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

Якщо ви оптимізуєте для однолітків (відкритих розробників ), мураха / make / що буде робити. Якщо ви надаєте функціонал іншим користувачам ( користувачам) ), це робитиме лише maven / gradle / тощо.

Тільки maven дозволяє випустити невеликий пакет вихідного коду + poms (відсутні вбудовані банки з ліцензійними / бінарними залежностями із криптованими іменами та відсутністю інформації про залежність) із добре задокументованим стандартним макетом проекту, який може завантажувати будь-який IDE хтось, хто не поглинув конвенції розробників про ідіосинкратичний макет. І є процедура встановлення однією кнопкою (mvn install), яка створює все, отримуючи будь-які відсутні залежності.

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

Крім цієї (неодмінної) вимоги, я не люблю maven так само, як будь-кого.