【问题标题】:How to properly use org.wildly wildfly-server dependency in pom.xml?如何在 pom.xml 中正确使用 org.wildly wildfly-server 依赖项?
【发布时间】:2015-02-19 10:01:06
【问题描述】:

我正在尝试为我当前的项目设置一个易于维护的 Maven 配置。带有两个 EJB 和一个 WAR 模块的 EAR 将部署到 JBoss Wildfly v8.2.0.Final,我想通过在我的pom.xml 中使用以下依赖项来简化构建过程:

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

我认为这将允许我使用所有提供的模块,如 EJB、CDI 和其他模块,而无需在我的模块 pom.xml 中明确命名它们。但情况似乎并非如此。我必须手动添加以下依赖项...真的需要吗?

<dependencies>
    <dependency>
        <groupId>org.jboss.spec.javax.interceptor</groupId>
        <artifactId>jboss-interceptors-api_1.2_spec</artifactId>
    </dependency>
    <dependency>
        <groupId>org.jboss.spec.javax.faces</groupId>
        <artifactId>jboss-jsf-api_2.2_spec</artifactId>
    </dependency>
    <dependency>
        <groupId>org.jboss.spec.javax.servlet</groupId>
        <artifactId>jboss-servlet-api_3.1_spec</artifactId>
    </dependency>
    <dependency>
        <groupId>org.jboss.spec.javax.ejb</groupId>
        <artifactId>jboss-ejb-api_3.2_spec</artifactId>
    </dependency>
    <dependency>
        <groupId>org.jboss.spec.javax.el</groupId>
        <artifactId>jboss-el-api_3.0_spec</artifactId>
    </dependency>
    <dependency>
        <groupId>org.jboss.spec.javax.transaction</groupId>
        <artifactId>jboss-transaction-api_1.2_spec</artifactId>
    </dependency>
</dependencies>

还是应该这样? How to use jars from Wildfly correctly in Maven? 目前还不清楚。

【问题讨论】:

  • 好像是这样......到目前为止没有其他回复。还必须将&lt;scope&gt;provided&lt;/scope&gt; 添加到所有依赖项。

标签: maven wildfly


【解决方案1】:

您要查找的不是 wildfly-server 的使用,它是作为启动服务器的入口点的工件,一般应用程序开发人员不需要。

您正在寻找可与 WildFly 搭配使用的 bom。

你可以在这里找到所有不同种类的炸弹https://github.com/wildfly/boms

包含您可以使用的所有依赖项

<dependencyManagement>
    <dependencies>
        <dependency>
           <groupId>org.wildfly.bom</groupId>
           <artifactId>jboss-javaee-7.0-with-all</artifactId>
           <version>8.2.1.Final</version>
           <type>pom</type>
           <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

【讨论】:

  • BOM 似乎并未包含 WildFly 提供的所有模块。我之前已经尝试过这种方法,但仍然必须手动将一些模块添加到父 POM 中,并且我必须查找已发布的特定版本。 &lt;artifactId&gt;wildfly-server&lt;/artifactId&gt; 包括适用于我的 AS 附带的所有模块(包括它们的版本)。
  • 为什么要使用作为服务器一部分的模块,与开发/部署 EE 项目无关?如果您要为 wildfly 编写扩展程序,那就另当别论了,但是对于面向用户的应用程序,bom 提供了几乎所有您需要的 API
  • &lt;artifactId&gt;commons-lang&lt;/artifactId&gt; 例如与 WildFly 捆绑在一起,但不是 BOM 的一部分...但它是 &lt;artifactId&gt;wildfly-server&lt;/artifactId&gt; 的一部分并正确命名了提供的版本。
  • 因为它是内部服务器模块,不打算被部署使用。它可以使用,但建议不要使用。所有此类模块都被标记为私有,因为它们可以在任何版本中更改而不会发出警告。您也可以在模块描述符 github.com/wildfly/wildfly/blob/master/feature-pack/src/main/… 中看到这一点
  • ...但我不需要将它添加到我的 EAR 中并让事情膨胀并引发冲突。无论如何,它是类路径的一部分,所以我不应该把它搞砸。我可以控制 JBoss WildFly 部署,因此可以随时验证提供的版本。
【解决方案2】:

如果您只需要 Java EE API,那么只需使用 Java EE API 依赖项即可。但是,您可能会在单元和低级集成测试期间遇到问题。

所以我使用的方法是 glassfish-embedded-all 依赖项,它至少是参考实现,并且为我很好地捆绑了所有内容。但是,我只推荐它仅用于测试 并且 需要 javaee 依赖项之前。

我在父 pom 中的核心依赖项通常如下所示

<dependencies>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.12</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>org.glassfish.main.extras</groupId>
        <artifactId>glassfish-embedded-all</artifactId>
        <version>4.1</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>javax</groupId>
        <artifactId>javaee-api</artifactId>
        <version>7.0</version>
        <scope>provided</scope>
    </dependency>
</dependencies>

通过使用这种方法,我可以两全其美。我可以针对参考实现运行低级集成测试,同时确保它在编译时仅针对标准 API 进行编译。

在 API 依赖项之前保留 glassfish-embedded-all 很重要,否则类加载器将首先选择 API 依赖项,这在测试期间不需要。

【讨论】:

  • 这不能回答我的问题...我想知道是否真的有必要手动添加所有这些依赖项。你指的是 GlassFish 而不是 WildFly。此外,除非我使用 &lt;scope&gt;compile&lt;/scope&gt;,否则我现在遇到 ClassNotFound 问题。
  • 我今天可以通过使用 jboss-deployment-structure.xml... 来解决我的类加载器问题...到目前为止一切顺利。
猜你喜欢
  • 1970-01-01
  • 2014-02-19
  • 1970-01-01
  • 2021-06-12
  • 1970-01-01
  • 2018-02-10
  • 2023-03-18
  • 2014-03-23
  • 1970-01-01
相关资源
最近更新 更多