Java Maven 类似于 npm 吗？

Is Maven similar to npm?

提问by Shubham Jain

As I have worked with npm which looks for dependencies in package.json file and download it for you. Similarly, I see a pom.xml file in Java project. Does maven looks in this file and download dependencies for me. Can I pass around this pom.xml file like package.json, rather than giving the dependency jars ? Are these tools similar and just build for different platforms ?

因为我使用过 npm，它会在 package.json 文件中查找依赖项并为您下载。同样，我在Java项目中看到了一个pom.xml文件。maven 是否会查看此文件并为我下载依赖项。我可以像 package.json 一样传递这个 pom.xml 文件，而不是提供依赖 jars 吗？这些工具是否相似并且只是为不同的平台构建？

采纳答案by Anton Koscejev

Same tool, different language?

相同的工具，不同的语言？

Maven is the most popular build and dependency resolution tool for Java, just like NPM is for JS. But it's not just the same tool for a different language. There are obviously huge differences between Java and JS builds, and these differences are directly visible in the way Maven operates. For example, while many JS tools rely on Git to do some heavy-lifting, Maven works with custom filesystem-based Maven repositories, as Maven predates Git and needs to handle binary artifacts, which Git historically didn't handle well. In Maven there's a clear separation between sources and binaries, while they are often the same thing in JS world.

Maven 是最流行的 Java 构建和依赖解析工具，就像 NPM 是 JS 一样。但这不仅仅是用于不同语言的相同工具。Java 和 JS 构建之间显然存在巨大差异，而这些差异直接体现在 Maven 的运行方式上。例如，虽然许多 JS 工具依赖 Git 来完成一些繁重的工作，但 Maven 可以使用基于自定义文件系统的 Maven 存储库，因为 Maven 早于 Git 并且需要处理二进制工件，而 Git 历史上不能很好地处理这些工件。在 Maven 中，源代码和二进制文件之间有明显的区别，而它们在 JS 世界中通常是同一回事。

Maven basics

Maven 基础知识

Maven in its purest form follows a declarative model, where pom.xml(similar to package.json) defines different properties of the build, but contains no scripts. The disadvantage is it can be a challenge to fine-tune some aspects of the build without using scripts as you have to rely on plugins. The advantage is it can be easier to understand other builds just by looking at pom.xml, as they usually follow the same approach without too much customization. Gradle is a popular Groovy-based tool built on top of Maven standards and conventions, and is specifically designed to simplify pom.xmland break this "no script" barrier.

Maven 以其最纯粹的形式遵循声明式模型，其中pom.xml（类似于package.json）定义了构建的不同属性，但不包含脚本。缺点是在不使用脚本的情况下微调构建的某些方面可能是一个挑战，因为您必须依赖插件。优点是只需查看 就可以更容易地理解其他构建pom.xml，因为它们通常遵循相同的方法而无需进行太多定制。Gradle 是一种流行的基于 Groovy 的工具，它构建在 Maven 标准和约定之上，专门设计用于简化pom.xml和打破这种“无脚本”障碍。

Referencing your dependencies

引用您的依赖项

Similarly to package.json, you don't work with pom.xmlof your dependency directly, but rather define dependency coordinates and let your build tool handle the rest. In Maven the basic form of these coordinates is GAV (groupId, artifactId, version).

与 类似package.json，您不pom.xml直接使用您的依赖项，而是定义依赖项坐标并让您的构建工具处理其余部分。在 Maven 中，这些坐标的基本形式是 GAV（groupId、artifactId、version）。

Flat dependency tree?

扁平依赖树？

Based on comments in the other answer, Maven provides "flat dependency tree", not "nested dependency tree" that NPM provides by default. Maven does not allow multiple versions of the same dependency. If it happens that different versions are requested, Maven uses dependency resolutionto pick a single version. This means that sometimes your transitive dependencies will get a different version than they require, but there are ways to manage this. However, this limitation comes from Java, not Maven, as (normally) in Java a class loader will only provide access to a single class definition even if multiple definitions are found on the classpath. Since Java is not particularly good at handling this, Maven tries to avoid this scenario in the first place.

根据另一个答案中的注释，Maven 提供了“平面依赖树”，而不是 NPM 默认提供的“嵌套依赖树”。Maven 不允许同一依赖项的多个版本。如果碰巧请求了不同的版本，Maven 会使用依赖项解析来选择单个版本。这意味着有时您的传递依赖项会获得与他们需要的版本不同的版本，但有一些方法可以管理它。但是，此限制来自 Java，而不是 Maven，因为（通常）在 Java 中，即使在类路径上找到多个定义，类加载器也只会提供对单个类定义的访问。由于 Java 不是特别擅长处理这个问题，Maven 首先试图避免这种情况。

Note: since npm v3 the dependencies are flatten. The alternative package manager yarnalso does the same.

注意：从 npm v3 开始，依赖项变平了。替代的包管理器纱线也有同样的作用。

Maturity

到期

Furthermore, Maven is considerably older than NPM, has a larger user base, huge number of custom plugins, and so far could probably be considered more mature overall. Sometimes Maven is used for non-Java or even polyglot projects, as there are plugins for handling other languages or specific environments, such as Android. There are plugins that bridge Maven and other build tools, such as frontend-maven-pluginthat actually handles multiple JS build tools.

此外，Maven 比 NPM 老得多，拥有更大的用户群，大量的自定义插件，到目前为止，整体上可能被认为更成熟。有时 Maven 用于非 Java 甚至多语言项目，因为有用于处理其他语言或特定环境（例如 Android）的插件。有一些插件可以连接 Maven 和其他构建工具，例如实际处理多个 JS 构建工具的frontend-maven-plugin。

回答by Apostolos

yes. it's a similar packaging tool for java. look for gradlealso which gives you more liberty with groovy language, but for start you can use mavento organize your dependencies. you include them as tags there and maven does the job for you.

是的。它是一个类似的 java 打包工具。寻找gradle也给你更多的自由groovy language，但首先你可以maven用来组织你的依赖项。你将它们作为标签包含在那里，maven 为你完成这项工作。

it traverses the dependency tree and downloads all the appropriate jars.

它遍历依赖树并下载所有适当的 jars。

回答by LEMUEL ADANE

Yes, same with gradle, but they are not user friendly as npm.

是的，与 gradle 相同，但它们不像 npm 那样用户友好。

回答by Marinos An

Below I use |to separate between maven | npm terms respectively:

下面我用|maven 来分隔 | npm 条款分别为：

Common features:

共同特征：

• Both tools support dynamic fetch of dependencies( artifacts | packages) based on a descriptor file pom.xml|package.json, and also allow you to deploy | publishyour own artifacts | packages.

• They both have a default public repository | registry( http://repo.maven.apache.org/maven2/| https://registry.npmjs.org), but 3rd-party can also be used (via settings.xml|.npmrc).

• They both support the concept of build-level dependencies (plugins | devDependencies used in scripts). *Maven supports provideddependencies also but this does not seem to apply to npm, since javascript is rarely deployed into containers.

• They both support dependency namespacing: groupId|scope

• 这两种工具都支持基于描述符文件的依赖项（工件 | 包）的动态获取pom.xml| package.json，还允许您部署 | 发布您自己的工件 | 包。

• 他们都有一个默认的公共存储库 | 注册表（http://repo.maven.apache.org/maven2/| https://registry.npmjs.org），但也可以使用 3rd-party （通过settings.xml|.npmrc）。

• 它们都支持构建级依赖的概念（插件 | 脚本中使用的 devDependencies）。*Mavenprovided也支持依赖关系，但这似乎不适用于 npm，因为 javascript 很少部署到容器中。

• 它们都支持依赖命名空间：groupId|scope

Differrences:

区别：

• maven has an additional local repository(cache):

  • No need to fetch again the same dependency for differrent projects.
  • Artifacts that are installed locally, are automatically accessible by other local projects.

• dependencies from a project build in maven are downloaded in <homedir>/.m2. With npm they are downloaded in <projectdir>/node_modules.

• Building in mavenis commonly a one-step process: mvn package(fetch deps , build). In npm it is a 2-step process: npm install(fetch deps) , npm build(build)

• maven defines build lifecycles(for building,testing,deploying) consisted of phases, to which default operations(plugin goals) attach, based on differrent packaging options(.jar,.war,.eare.t.c). You can then overwrite these operations, or inject new ones (via the plugin system). This provides kind of an out-of-the box solution for build,docgen,test,deploy e.t.c.
  npm approach is more simplistic ( see: scripts)

• Due to the above, npm is labeled as a package-management tool for javascriptwhile maven is labeled as a build-automation and dependency-management tool for java.

• In maven setting-up the build process more commonly involves editing the pom.xml.
  In npm it involves writing codeor configuring complementary build toolslike gulp,webpacke.t.c

• For some reason version rangesdefined by users in npm modules, are much more loosethan in maven. This can cause issues with transitive dependencies, that is why an additional file was recently added: package-lock.json

• With npm it is much more straightforward to starta new project: npm init. With maven, you need to know how to write a minimal pom.xml, or read about archetypes.

• In general it is much more common to edit pom.xmlthan package.json. E.g. adding dependencies in mavenis done manually(or via IDE) while in npm via command line.

• As with all build tools, you can call one tool from inside the other, but I think its much more common to call npm from inside maven, than the opposite.

• npm supports dev,production builds. In maven this needs to be defined through profiles.

• maven 有一个额外的本地存储库（缓存）：

  • 无需为不同的项目再次获取相同的依赖项。
  • 本地安装的工件可被其他本地项目自动访问。

• 来自 Maven 项目构建的依赖项在<homedir>/.m2. 使用 npm，它们以<projectdir>/node_modules.

• 在maven 中构建通常是一个一步过程：（mvn package获取 deps ，构建）。在 npm 中，它是一个 2 步过程：npm install(fetch deps) , npm build(build)

• 行家定义构建生命周期（用于构建，测试，部署）由阶段，到默认操作（插件的目标）连接，基于differrent封装选项（.jar，.war，.ear等）。然后您可以覆盖这些操作，或注入新的操作（通过插件系统）。这为构建、文档生成、测试、部署等提供了一种开箱即用的解决方案，
  npm 方法更简单（请参阅： 脚本）

• 由于上述原因，npm 被标记为 javascript的包管理工具，而 maven 被标记为 java的构建自动化和依赖项管理工具。

• 在 maven 设置中，构建过程更常见地涉及编辑pom.xml.
  在NPM它涉及编写代码或配置辅助生成工具一样gulp，webpack等

• 由于某些原因，用户在 npm 模块中定义的版本范围比在 maven 中宽松得多。这可能会导致传递依赖问题，这就是最近添加了一个附加文件的原因：package-lock.json

• 使用 npm开始一个新项目要简单得多：npm init. 使用 maven，您需要知道如何编写一个 minimumpom.xml或阅读原型。

• 一般来说，编辑pom.xml比package.json. 例如在行家添加依赖完成手动（或经由IDE），而在NPM通过命令行。

• 与所有构建工具一样，您可以从另一个工具内部调用一个工具，但我认为从 maven 内部调用npm比相反更常见。

• npm 支持开发、生产构建。在 maven 中，这需要通过配置文件来定义。