Поскольку я работал с npm, который ищет зависимости в файле package.json и загружает его для вас. Точно так же я вижу файл pom.xml в проекте Java. Смотрит ли maven в этот файл и скачивает ли мне зависимости. Могу ли я передать этот файл pom.xml, например package.json, вместо того, чтобы указывать jar-файлы зависимостей? Эти инструменты похожи и созданы для разных платформ?
Ответы:
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, version).
Основываясь на комментариях в другом ответе, 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 определяет жизненные циклы сборки (для сборки, тестирования, развертывания), состоящие из фаз, к которым присоединяются операции по умолчанию (цели плагина) , на основе различных вариантов упаковки ( .jar, .warи .earт. д.). Затем вы можете перезаписать эти операции или ввести новые (через систему плагинов). Это обеспечивает своего рода готовое решение для сборки, документирования, тестирования, развертывания и т. Д.
Подход npm более упрощен (см. Сценарии )
Из-за вышесказанного npm помечен как инструмент управления пакетами для javascript, а maven - как автоматизации сборки и управления зависимостями для java .
При настройке maven процесс сборки чаще всего включает редактирование файлаpom.xml .
В npm это включает в себя написание кода или настройку дополнительных инструментов сборки, таких какgulp ,webpack т. Д.
По какой-то причине диапазоны версий, определенные пользователями в модулях npm, намного более свободны, чем в maven. Это может вызвать проблемы с транзитивными зависимостями, поэтому недавно был добавлен дополнительный файл:package-lock.json
С npm начать новый проект намного проще :npm init . С maven вам нужно знать, как писать минимал pom.xml, или читать об архетипах.
В общем, редактировать гораздо чаще, pom.xmlчем файлы package.json. Например, добавление зависимостей в maven выполняется вручную (или через IDE), а в npm - через командную строку .
Как и в случае со всеми инструментами сборки, вы можете вызывать один инструмент изнутри другого, но я думаю, что гораздо чаще вызывать npm изнутри maven , чем наоборот.
npm поддерживает dev, производственные сборки . В maven это нужно определять через профили .
да. это аналогичный инструмент для упаковки java. ищите gradleтакже, что дает вам больше свободы groovy language, но для начала вы можете использоватьmaven для организации своих зависимостей. вы включаете их как теги, и maven сделает всю работу за вас.
он просматривает дерево зависимостей и загружает все соответствующие jar-файлы.
gradleэто maven + antвместе скажем. он делает то же самое, что и maven, но дает вам также свободу писать код и сценарии помимо всех фактических задач, которые он выполняет. я только что посмотрел gulp. может быть, это то же самое, что я читал. если вы хотите начать использовать maven vs gradle, я бы посоветовал начать с того, mavenчто более понятно и легче понять, а затем испортить gradle!
Да, то же самое с gradle, но они не удобны для пользователя, как npm.