Оскільки я працював з npm, який шукає залежності у файлі package.json і завантажує його для вас. Так само я бачу файл pom.xml у проекті Java. Чи шукає maven цей файл та завантажує залежності для мене. Чи можу я передати цей файл pom.xml, такий як package.json, а не надавати банки залежностей? Чи подібні ці інструменти і просто створюються для різних платформ?
Відповіді:
Maven - найпопулярніший інструмент збірки та вирішення залежностей для Java, як і NPM для JS. Але це не просто той самий інструмент для іншої мови. Очевидно, що між побудовами Java та JS є величезні відмінності, і ці відмінності безпосередньо видно з того, як працює Maven. Наприклад, в той час як багато інструментів JS покладаються на Git для важкого підйому, Maven працює зі спеціальними сховищами Maven на основі файлової системи, оскільки Maven передує Git і повинен обробляти двійкові артефакти, з якими Git історично не справлявся. У Maven існує чітке розділення між джерелами та двійковими файлами, хоча в світі JS вони часто однакові.
Maven у чистому вигляді дотримується декларативної моделі, де pom.xml(подібно до package.json) визначає різні властивості збірки, але не містить сценаріїв. Недоліком є те, що може бути складно налаштувати деякі аспекти збірки без використання сценаріїв, оскільки вам доведеться покладатися на плагіни. Перевага полягає в тому, що легше зрозуміти інші збірки, просто подивившись pom.xml, оскільки вони, як правило, застосовують один і той же підхід без зайвих налаштувань. Gradle - це популярний інструмент на основі Groovy, побудований на основі стандартів та конвенцій Maven і спеціально розроблений для спрощення pom.xmlта подолання цього бар'єру "без сценарію".
Подібно до цього package.json, ви не працюєте безпосередньо зі pom.xmlсвоєю залежністю, а навпаки, визначаєте координати залежностей, і дозволяєте інструменту побудови обробляти все інше. У Maven основною формою цих координат є GAV (groupId, artifactId, версія).
На основі коментарів в іншій відповіді Maven надає "плоске дерево залежностей", а не "вкладене дерево залежностей", яке NPM надає за замовчуванням. Maven не допускає декілька версій однієї і тієї ж залежності. Якщо трапляються запити на різні версії, Maven використовує дозвіл на залежність, щоб вибрати одну версію. Це означає, що іноді ваші транзитивні залежності отримають іншу версію, ніж вони вимагають, але є способи управління цим. Однак це обмеження походить від Java, а не від Maven, оскільки (як правило) в Java завантажувач класів надає доступ лише до одного визначення класу, навіть якщо на шляху до класу знайдено кілька визначень. Оскільки Java не особливо добре справляється з цим, Maven намагається уникати цього сценарію.
Примітка: з npm v3 залежності згладжуються. Альтернативна пряжа менеджера пакетів також робить те ж саме.
Крім того, Maven значно старший за NPM, має більшу базу користувачів, величезну кількість користувацьких плагінів, і досі, мабуть, може вважатися більш зрілим в цілому. Іноді Maven використовується для проектів, що не пов'язані з Java, або навіть для поліглотів, оскільки існують плагіни для обробки інших мов або певних середовищ, таких як Android. Є плагіни, які поєднують Maven та інші інструменти побудови, такі як frontend-maven-plugin, який насправді обробляє кілька інструментів побудови JS.
Нижче я використовую |для розділення між maven | npm умови відповідно:
Обидва інструменти підтримують динамічне отримання залежностей ( артефакти | пакети ) на основі файлу дескриптора pom.xml| package.json, а також дозволяють розгортати | публікувати власні артефакти | пакунки .
Вони обидва мають загальнодоступне сховище | реєстру ( http://repo.maven.apache.org/maven2/ | https://registry.npmjs.org ), але також можна використовувати сторонні (через settings.xml|.npmrc ).
Вони обидва підтримують концепцію залежностей рівня побудови (плагіни | devDependencies, що використовуються в сценаріях) . * Maven також підтримує providedзалежності, але, схоже, це не стосується npm, оскільки javascript рідко розгортається в контейнерах.
Вони обидва підтримують простір імен залежностей: groupId|scope
maven має додаткове локальне сховище (кеш):
Залежності від збірки проекту в maven завантажуються в <homedir>/.m2. З npm вони завантажуються в <projectdir>/node_modules.
Будівництво в maven - це зазвичай одноетапний процес : mvn package(дістати депи, побудувати). У npm це двохетапний процес: npm install(отримати деп), npm build(побудувати)
Maven визначає побудови життєвого циклу (для створення, тестування, розгортання) складалася з етапів, до яких по замовчуванням операції (плагін мети) кріплять на основі differrent варіантів упаковки ( .jar, .war, і .earт.д.). Потім ви можете перезаписати ці операції або ввести нові (через систему плагінів). Це забезпечує своєрідне нестандартне рішення для збірки, документації, тестування, розгортання тощо.
Підхід до npm є більш спрощеним (див .: сценарії )
Завдяки вищевикладеному, npm позначений як інструмент управління пакетами для javascript, тоді як maven позначений як інструмент автоматизації збірки та управління залежностями для Java .
У налаштуваннях maven процес збірки частіше включає редагуванняpom.xml .
У НОЙ вона включає в себе написання коду або налаштування додаткових інструментів збірки , як gulp, і webpackт.д.
Чомусь діапазони версій, визначені користувачами в модулях npm, набагато більш вільні, ніж у maven. Це може спричинити проблеми з перехідними залежностями, тому нещодавно був доданий додатковий файл:package-lock.json
З НПМ набагато більш простим , щоб почати новий проект: npm init. З Maven ви повинні знати, як написати мінімум pom.xml, або прочитати про архетипи.
Взагалі редагувати набагато частіше, pom.xmlніж package.json. Наприклад, додавання залежностей у maven здійснюється вручну (або через IDE), а в npm за допомогою командного рядка .
Як і у всіх інструментах побудови, ви можете викликати один інструмент зсередини іншого, але я думаю, що набагато частіше викликати npm зсередини maven , ніж навпаки.
npm підтримує розробник, виробничі збірки . У maven це потрібно визначати за допомогою профілів .
так. це подібний пакувальний інструмент для Java. шукайте gradleтакож, що надає вам більше свободи groovy language, але для початку ви можете використовувати mavenдля упорядкування своїх залежностей. ви включаєте їх там як теги, і maven виконує роботу за вас.
він обходить дерево залежностей і завантажує всі відповідні банки.
gradleце maven + antразом скажемо. він робить те, що робить maven, але дає вам також свободу писати код і сценарії, крім усіх фактичних завдань, які він робить. я gulpзараз подивився . можливо, це те саме, з прочитаного. якщо ви хочете почати використовувати maven vs gradle, я б запропонував почати з того, mavenщо є більш зрозумілим та легшим для розуміння, а потім зіпсувати gradle!
Так, те саме з gradle, але вони не зручні для користувача, як npm.