How to properly declare Server Runtime dependency or provided by Wildfly in Gradle

Question

How to properly declare Server Runtime dependency or provided by Wildfly in Gradle

Navigation

#1 by (2 votes)

3

I have a Java web project being developed to run on Wildfly, using the Eclipse IDE. This application uses JPA, JTA, JSF, and CDI at first, but will use other Java EE features in the future. The dependency control of this project is done by Gradle, but as you can see in the build.gradle below, I declare none of the dependencies already present in Wildfly:

apply plugin: 'war'
apply plugin: 'eclipse-wtp'

sourceCompatibility = 1.8
version = '1.0'
jar {
    manifest {
        attributes 'Implementation-Title': 'Arch Project', 'Implementation-Version': version
    }
}

repositories {
    mavenCentral()
}

So, to add Java EE dependencies I add a library of type Server Runtime into my project, in other words, I right click on my project - > Configure Build Path - > , select Server Runtmime and finally select the server Wildfly that I configured in my Eclipse.

The above configuration leaves my project with 3 libraries

JRE System Library
Gradle Dependencies (empty)
Wildfly 8.2 Runtime

Problem

So, I can run my application on Wildfly (right click on the project -> Run As - > Run on Server , however, if I try to build my .war using the gradle through the gradle war command, it obviously gives error, accusing the Wildfly classes are not in the classpath.

Solutions

Declare the dependencies of JPA, JTA, JSF, and CDI with scope provided in build.gradle :

Pro: I've seen something similar in maven projects and made it clear to other developers which dependencies are used. Home
To avoid bugs I will have to pay attention to the versions of the APIs used by Wildfly, and with each new dependency, I will have to open the Wildfly documentation and search for the correct version of the jar, to add the same version as dependency provided on my gradle.

Somehow similar to Eclipse, add the dependency of a server runtime to my build.gradle.

Pro: If it works correctly, I'll make sure I'm using the same libraries that will be fetched when the application is running on the server, avoiding surprises from different versions or even the famous ClassNotFoundException for having developed with more modern APIs. who are in the Wildfly.
I do not even know if this is possible, and if it is, I believe that every user who downloads the project on his machine will have to manually configure the Wildfly path for Gradle to find.

I would like to know which solution is most appropriate, and if it is the second one, how would this configuration be performed.

Thank you in advance.

java java-ee gradle wildfly

asked by anonymous 26.01.2015 / 17:12

1 answer

Search the data of the last 7 days from the current date (2014-12-11 11:06:09) Error Restricting Dates in SQL Server

score 2 · Accepted Answer

While both solutions seem to be acceptable, the second includes an external (implicit) dependency on the IDE. That way, the first solution seems to me the most appropriate.

On the versions of the APIs used by Wildfly, I would not worry about that much. In fact, for Java EE services you generally only need to depend on the interfaces / APIs.

In many projects a simple dependency for javaee-api is enough:

configurations {
    provided
}

sourceSets {
    main.compileClasspath += configurations.provided
    test.compileClasspath += configurations.provided
    test.runtimeClasspath += configurations.provided
}

dependencies {
    provided 'javax:javaee-api:7.0'
}

In order to avoid problems with version differences between some APIs present simultaneously in the JVM (Java SE) and in your application server (Java EE) it is also interesting to configure Java EE Endorsed Api . For more information on how to do this in gradle see this post .

For individual Java EE APIs, see this listing . p>

Of course, you may want to use non-standard APIs, for example, Hibernate annotations. In this case you will also need to include provided pendencies for the libraries. These are the most difficult cases to administer (as you've come to the question), since there may be a breach of compatibility if the graddle settings do not reflect the exact reality of the application server. The ideal is to reduce the amount of dependencies of this type. Those premises that are strictly necessary should be highlighted; it is also interesting to create mechanisms to help you upgrade versions (e.g., properties for well-known versions to maven style).