Question

我正在调用这样的deploy-file将一些JAR加载到我的公司存储库中：

mvn org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy-file \
  -Dfile=lib/SomeLib.jar \
  -DrepositoryId=mycompany-central \
  -Durl=http://myserver/artifactory/libs-release-local -DgeneratePom=false \
  -DgroupId=com.some.lib \
  -DartifactId=SomeLib \
  -Dversion=1.2.5.3

我假设我想要尽可能少地生成或更改，我将generatePom设置为false。我加载的库碰巧是使用maven构建的，并且还包含META-INF下的POM。

问题：在一般条件下，generatePom应该设置为false？在我的情况下generatePom应该设置为false吗？

Answer 1

传递依赖项需要pom.xml文件。传递依赖性是dependencies部分中定义的依赖关系，如果有的话，.pom文件可用作部署的人工制品的一部分。

.pom文件基本上是原始pom.xml文件的副本，已重命名以反映库名称（即artifactId-version.jar，然后是artifactId-version.pom）。

在解析依赖项时，maven还会检查其.pom文件，并因此获取有关其依赖项的信息（然后成为传递依赖项）并构建（并获取）所需的依赖项图（即，为每个声明的依赖项重新迭代相同的进程。

来自官方Maven - Introduction to the dependency mechanism

通过从指定的远程存储库中读取依赖项的项目文件，可以简化此功能。通常，这些项目的所有依赖项都在项目中使用，项目从其父项或其依赖项继承的任何依赖项都是如此。

注意：大胆是我的。 项目文件通常是pom.xml文件，一旦相关工件上传到Maven存储库（或安装到本地Maven缓存中），就会重命名为*.pom文件。

使用-DgeneratePom=false，我们应该通过pomFile选项传递pom.xml文件，否则（将generatePom设置为true）新的文件将是automatically generated

如果没有通过参数pomFile提供，则为工件生成最小POM。如果本地存储库中还没有现有POM，则默认为true。

自动生成的.pom文件几乎为空（Maven坐标（groupId，artifactId，version）但其中没有dependencies部分），因此Maven会将此artefact视为没有传递依赖的库：它找不到任何东西，也无法猜测。

如果实际上不需要传递依赖，那仍然可以。否则，当使用is作为另一个Maven项目中的依赖项时，将发生编译（或运行时）错误。相反，如果将人工制品部署到构建存储中，则传递依赖性变得不那么重要，并且自动生成的pom仍然可以正常。

来自您的评论：

生成的pom和使用从JAR中提取的pom之间有什么区别吗？

如上所述，自动生成的文件与原始pom.xml文件之间存在很大差异。但是，如果目标工件将被另一个项目用作maven依赖，那么这种差异基本上是很重要的。存储在pom.xml下的META-INF文件通常是原始文件的副本。

另外，如果我使用来自JAR的pom将部署文件，只需从文件中获取工件名称，groupId和版本？

是的，正如official documentation所指定的那样：

groupId：要部署的工件的GroupId。如果指定，则从POM文件中检索。 artifactId：要部署的工件的ArtifactId。如果指定，则从POM文件中检索。 version：要部署的工件的版本。如果指定，则从POM文件中检索。

还由the official example

指定

请注意，groupId，artifactId，版本和打包信息会自动从给定的pom中检索。

什么时候应该为maven deploy-file的generatePom设置为false？

1 个答案: