0

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.

Community
  • 1
  • 1
Daniel Bleisteiner
  • 3,190
  • 1
  • 33
  • 47

2 Answers2

1

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>
Tomaz Cerar
  • 5,761
  • 25
  • 32
  • The BOM doesn't seem to include all modules provided by WildFly. I've tried that approach earlier and some modules still had to be added manually to the parent POM and I had to look for the specific versions that are shipped. `wildfly-server` includes **all** modules (including their versions) that ship with the AS which works for me. – Daniel Bleisteiner Feb 24 '15 at 05:44
  • Why would you want to use module that are part of server and have nothing to do with developing / deploying EE projects? If you would be writing Extension to wildfly than that would be different story, but for user facing applications boms provide pretty much all APIs you need – Tomaz Cerar Feb 24 '15 at 09:47
  • `commons-lang` for example is bundled with WildFly but not part of the BOM... but it is part of `wildfly-server` and properly names the provided version. – Daniel Bleisteiner Feb 24 '15 at 12:09
  • As it is internal server module, not meant to be used by deployments. It can be used but it is advised against. All such modules are marked as private as they can change in any version without warning. You can see that also in module descriptors https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/resources/modules/system/layers/base/org/apache/commons/lang/main/module.xml#L27 – Tomaz Cerar Feb 24 '15 at 14:29
  • ...but I don't need to add this to my EAR and bloat things up and provoke conflicts. It is part of the classpath anyway and so I should not mess this up. I'm in control over the JBoss WildFly deployment and therefore can always verify the provided version. – Daniel Bleisteiner Feb 25 '15 at 08:57
0

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.

Archimedes Trajano
  • 35,625
  • 19
  • 175
  • 265
  • That doesn't answer my question... I wondered if it's really necessary to add all those dependencies manually. And you refer to GlassFish instead of WildFly. Further more I'm now having issues with ClassNotFound unless I use `compile`. – Daniel Bleisteiner Feb 19 '15 at 10:54
  • I could solve my class loader problems today by using a `jboss-deployment-structure.xml`... so far so good. – Daniel Bleisteiner Feb 19 '15 at 20:16