Daniel Bleisteiner
Daniel Bleisteiner

Reputation: 3310

How to properly use org.wildly wildfly-server dependency in pom.xml?

I'm trying to setup an easy to maintain Maven config for my current project. The EAR with two EJB und one WAR module will be deployed to JBoss Wildfly v8.2.0.Final and I want to ease the build process by using the following dependency in my 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>

I've thought this would allow me to use all the provided modules like EJB, CDI and the others without explicitly naming them in my modules pom.xml. But that doesn't seem to be the case. I had to add the following dependencies manually... is this really needed?

<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>

Or is this the way it should be? How to use jars from Wildfly correctly in Maven? is not clear at this point.

Upvotes: 0

Views: 4084

Answers (2)

Tomaz Cerar
Tomaz Cerar

Reputation: 5791

What are you looking for is not usage of wildfly-server, which is artifact that is entry point for booting the server and not needed by application developers in general.

You are looking for boms that go with WildFly.

you can find all different kind of boms here https://github.com/wildfly/boms

to include all dependencies you could use

<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>

Upvotes: 1

Archimedes Trajano
Archimedes Trajano

Reputation: 41220

If you only need the Java EE API then just use the Java EE API dependency. However, you may hit issues during unit and low-level integration testing.

So the approach I use is the glassfish-embedded-all dependency which is at least the reference implementation and bundles everything up nicely for me. However, I only recommend it only for testing and needs to be before the javaee dependency.

My core dependencies in my parent pom usually looks like this

<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>

By using this approach I get the best of both worlds. I can run low level integration tests against a reference implementation while I ensure that when it compiles it only compiles against the standard API.

It is important you keep the glassfish-embedded-all before the API dependency otherwise the classloader will pick the API dependency first which isn't want you want during testing.

Upvotes: 0

Related Questions