project.parent.name和parent.name之间的区别以及pom.xml中finalName的使用 [英] Difference between project.parent.name and parent.name ans use of finalName in pom.xml

问题描述

研究线程具有显式finalName的Maven无法正常工作正确.我想知道-

问题1 -maven的pom.xml中project.parent.attribute和parent.attribute有什么区别?

当前使用Maven 3.3.9和intellJ作为IDE，我所看到的是两个属性都导航到相同的属性.也是

Currently using Maven 3.3.9 along with intellJ as IDE all I get to see is both the properties navigate to the same attribute. Also a thought to the fact that

<project>是描述符的根.

用于定义任何pom.xml，在这种情况下，project.parent.*对于模块将等同于parent.*.

for defining any pom.xml, in which case project.parent.* shall be equivalent to parent.* for a module.

问题2 -如果上面的解释是正确的，那么finalName属性是否在其子模块pom调用父级的<name>属性时会覆盖父级的<name>属性? .xml?

Question 2 - If the above explanation is justified, then does the finalName attribute overrides the <name> attribute of a parent when called by its child module pom.xml?

问题3 -父模块finalName中${project.name}的值是什么?是父级的name还是最里面的[打包为jar，war等]子级的name?

Question 3 - What is the value of ${project.name} in the finalName of a parent module? Is it the name of the parent OR the name of the innermost [packaged as jar, war etc] child?

推荐答案

包含链接/示例的扩展答案

expanded answer with links / examples

project.parent.attribute是访问父项目属性的正确方法. parent.attribute指向相同的值，但已被弃用(Maven 3.3+在构建开始时确实抱怨过)

project.parent.attribute is the correct way to access parent project properties. parent.attribute points to the same value, but is deprecated (which Maven 3.3+ does clearly complain about at the beginning of the build)

(请参见模型构建器，其中指出: *和pom.*访问已被弃用)

(see Model Builder, which states that * and pom.* access is deprecated)

name和finalName完全无关. name是项目的明文名称(并且是子项目从未继承的少数元素之一)，finalName是工件文件的名称.

name and finalName are completely unrelated. name is a clear text name of the project (and is one of the few elements never inherited by child projects), finalName is the name of the artifact file.

如 POM参考所述:

finalName :这是捆绑项目最终构建时的名称(不带文件扩展名，例如:my-project-1.0.jar).默认为$ {artifactId}-$ {version}.

finalName: This is the name of the bundled project when it is finally built (sans the file extension, for example: my-project-1.0.jar). It defaults to ${artifactId}-${version}.

名称:项目通常具有会话名称，超出了artifactId.

name: Projects tend to have conversational names, beyond the artifactId.

所以这两个有不同的用途.

So these two have different uses.

• name仅用于提供信息，主要用于生成的文档和构建日志中.它不会被继承或在其他任何地方使用.它是人类可读的字符串，因此可以包含任何字符，即空格或文件名中不允许的字符.因此，这将是有效的:<name>My Turbo Project on Speed!</name>.显然，这至少是工件的可疑文件名.

• name is purely informational and mainly used for generated documentation and in the build logs. It is not inherited nor used anywhere else. It is a human readable String and can thus contain any character, i.e. spaces or characters not allowed in filenames. So, this would be valid: <name>My Turbo Project on Speed!</name>. Which is clearly at least a questionable file name for an artifact.

，finalName是生成的工件的名称.它是继承的，因此通常应依赖属性.仅有的两个真正有用的选项是默认的${artifactId}-${version}和无版本的${artifactId}.其他所有事情都会导致混乱(例如，名为foo的项目创建了工件bar.jar).其实，我的涡轮增压项目！会是有效的，因为这是有效的文件名，但实际上，这样的文件名似乎相当不可用(例如，尝试从bash中获取包含！的文件名)

as stated above, finalName is the name of the generated artifact. It is inherited, so it should usually rely on properties. The only two really useful options are the default ${artifactId}-${version} and the versionless ${artifactId}. Everything else leads to confusion (such as a project named foo creating an artifact bar.jar). Actually, My turbo Project! would be valid, since this is a valid filename, but in reality, filenames like that tend to be rather unusable (try adressing a filename containing ! from a bash, for example)

在pom的解析中，首先按顺序应用所有父级，然后才解析属性(始终针对当前项目).因此，该名称将是最里面子项的名称(但是，请参见上文:请勿使用project.name，因为它可能包含空格和其他非法字符)

In the resolution of the pom, first all parents are applied in order, and only then properties are resolved (always against the current project). So the name would be the name of the innermost child (however, see above: do not use project.name, as it might contain spaces and other illegal characters)

有关更多详细信息，请参见模型生成器.相关步骤标记为粗体:

see Model Builder for more details, the relevant steps here are marked bold:

• 阶段1
  • 个人资料激活:查看可用的激活器.请注意，尚未进行模型插值，因此基于文件的激活的插值仅限于$ {basedir}(自Maven 3起)，系统属性和请求属性
  • 原始模型验证:ModelValidator(javadoc)，及其DefaultModelValidator实现(源)
    • 模型规范化-合并重复项:ModelNormalizer(javadoc)，及其DefaultModelNormalizer实现(源)
    • 配置文件注入:ProfileInjector(javadoc)，及其DefaultProfileInjector实现(源)
    • 父级分辨率直到超级球
    • 继承程序集:InheritanceAssembler(javadoc)，及其DefaultInheritanceAssembler实现(源).请注意project.url，project.scm.connection，project.scm.developerConnection，project.scm.url和project.distributionManagement.site.url具有特殊处理:如果未在child中覆盖，则默认值为父级与child的默认值.附加了工件ID
    • 模型插值(见下文)
    • URL规范化:UrlNormalizer(javadoc)，及其DefaultUrlNormalizer实现(源)

• phase 1
  • profile activation: see available activators. Notice that model interpolation hasn't happened yet, then interpolation for file-based activation is limited to ${basedir} (since Maven 3), System properties and request properties
  • raw model validation: ModelValidator (javadoc), with its DefaultModelValidator implementation (source)
    • model normalization - merge duplicates: ModelNormalizer (javadoc), with its DefaultModelNormalizer implementation (source)
    • profile injection: ProfileInjector (javadoc), with its DefaultProfileInjector implementation (source)
    • parent resolution until super-pom
    • inheritance assembly: InheritanceAssembler (javadoc), with its DefaultInheritanceAssembler implementation (source). Notice that project.url, project.scm.connection, project.scm.developerConnection, project.scm.url and project.distributionManagement.site.url have a special treatment: if not overridden in child, the default value is parent's one with child artifact id appended
    • model interpolation (see below)
    • url normalization: UrlNormalizer (javadoc), with its DefaultUrlNormalizer implementation (source)

给定两个文件(仅相关部分):

So given two files (only relevant parts):

<artifactId>parent</artifactId>

<name>Parent Project</name>

<properties>
  <myProp>in-parent</myProp>
</properties>

<build>
  <finalName>${project.artifactId}-${myProp}</finalName>
</build>

孩子

<parent>
    <artifactId>parent</artifactId>
</parent>
<artifactId>child</artifactId>

<properties>
  <myProp>in-child</myProp>
</properties>

这些步骤按以下顺序执行(仅两个重要步骤):

The steps are performed in the following order (only the two important steps):

• 创建一个世代pom"，其中包含超级pom之前所有pom的内容:

<parent>
    <artifactId>parent</artifactId>
</parent>
<artifactId>child</artifactId> <!-- artifact id is never inherited -->

<!-- name is NOT inherited, so no name for child -->

<properties>
  <myProp>in-child</myProp> <!-- from child -->
</properties>

<build> <!-- inherited from parent -->
  <finalName>${project.artifactId}-${myProp}</finalName>
</build>

不是世代pom仍然只包含属性，而没有值.

Not that the generational pom still only contains the properties, not there values.

最后，在模型插值中，解析出属性.在此步骤中，不再使用父pom，在上一步之后，仅对当前项目的(世代)模型进行所有操作:

Finally, in Model interpolation, the properties are resolved. In this step, the parent pom is not used anymore, after the previous step, everything is ONLY done on the (generational) model of the current project:

<parent>
    <artifactId>parent</artifactId>
</parent>
<artifactId>child</artifactId> <!-- artifact id is never inherited -->

<!-- name is NOT inherited, so no name for child -->

<properties>
  <myProp>in-child</myProp> <!-- from child -->
</properties>

<build> <!-- inherited from parent -->
  <finalName>child-in-child</finalName> <!-- resolved against generational pom -->
</build>

---

通常来说，finalName应谨慎使用.删除本地生成的工件中的版本以使在本地容器中进行测试更容易(${project.artifactId}而不是默认的${project.artifactId}-${project.version})可能会很有用，但是我强烈建议您不要使用其他任何东西，因为上传的工件(到仓库)将始终具有原始的artifactId作为文件名，并且对于同一文件使用不同的名称可能会造成混淆.

---

Generally spoken, finalName should be used with care. It can be useful to remove the version in the locally generated artifact to make testing in a local container easier (${project.artifactId} instead of the default ${project.artifactId}-${project.version}), but I strongly advise against using anything else, because the uploaded artifact (to the repository) will have the original artifactId as filename anyway, and it might confuse to have to different names for the same file.

这篇关于project.parent.name和parent.name之间的区别以及pom.xml中finalName的使用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！