Maven org.wildfly.bom与所使用的wildfly服务器版本之间是否存在链接？

我目前正在开发一些应用程序，并使用wildfly 9.0.2.Final作为应用程序服务器。目前，我正在为以下工件使用bom版本8.2.2.Final：

• jboss-javaee-7.0-with-tools
• jboss-javaee-7.0-with-hibernate
• jboss-javaee-7.0-with-security

我在学习教程的同时开始使用这些版本。然而，我已经看到，现在wildfly 10已经发布了，可能其他一些依赖项也有依赖项。也许将来javaee-8.0将可用

---

在升级父bom版本时，是否有关于不同工件包括哪些内容以及可能需要记住哪些内容的文档？

您的bom版本应该与部署Wildfly版本匹配

假设您对Wildfly提供的依赖项使用了

提供的

范围，那么您需要确保使用的是正确的版本。如果使用错误的版本，应用程序可能无法按预期工作，甚至无法启动，因为某些API可能已被弃用/删除，或者某些功能可能尚未可用

---

旁注：Wildfly BOM表，因此我们使用父项作为BOM表：

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.wildfly</groupId>
            <artifactId>wildfly-parent</artifactId>
            <version>9.0.2.Final</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

野生蝇
野蝇亲本
9.0.2.1最终版本
聚甲醛
进口

对于WildFly 9+BOM表，我们稍微改变了结构，所以现在我们只有2个BOM表。 其中大部分被合并为一个

• wildfly-javaee7
• wildfly-javaee7-with-tools

其中第二个不仅包括API，还包括对测试有用的工具，如arquillian、junit等

因此，最好在pom.xml中使用它

<dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.wildfly.bom</groupId>
                <artifactId>wildfly-javaee7-with-tools</artifactId>
                <scope>import</scope>
                <type>pom</type>
                <version>10.0.0.Final</version>
            </dependency>
        </dependencies>
    </dependencyManagement>

org.wildfly.bom
您好，谢谢您的回答。因此，如果我理解正确，我只需要将jboss-javaee-7.0-with-hibernate等工件保持在当前版本，并增加wildfly父工件的版本。
jboss-javaee-7.0-with-hibernate
是BOM，其目的是定义依赖关系管理。根据我的经验，使用
wildfly-parent
进行依赖关系管理就足够了，您实际上并不需要两者兼而有之。您需要的是定义您使用的实际依赖项，例如RESTEasy、Weld等，但它们应该具有
提供的范围
，因此您不会将它们包括在最终WAR中，而是允许Wildfly提供它们。我不建议将项目父级POM用作BOM。这将带来不应暴露于部署的依赖项。顺便说一句，父项是一部分。然而，我仍然支持它。父项指定的唯一依赖项是
wildfly checkstyle config
，其他所有内容都在
dependencyManagement
中，并且只定义使用的版本（除非被重写），但不会引入依赖项！当您需要BOM中不包含的内容时，它比备选方案要好。不确定Wildfly 10个BOM表，但9个BOM表相当糟糕。@AntonKoscejev Wildfly 9/10 BOM表的“坏”到底是什么？您不需要构成服务器本身的所有内部依赖项，BOM只提供部署可以访问的内容和被视为API的内容，很少有情况下需要根据某个组件的确切实现版本而不是很少更改的API进行编码。bom总是有改进的空间，但在没有任何实际案例的情况下抛出指控/假设只是一种不好的做法。如果您发现boms中有任何未解决的问题，请访问