I am working on a Project that is deployed as .war WebApp on a single WildFly 16 instance.
Using IntelliJ Idea UE with Maven as development environment, I ask myself how to reflect the classpath that the deployed app will see at runtime in the development classpath at development time.
I have read about implicit dependencies in the Developer Guide.
So I conclude that the classpath of my deployment will contain the elements from the "Dependencies that are always added" column plus those that are added on trigger conditions (in my case these are Weld, Web, Hibernate, Resteasy, EJB3).
How can I figure out what Maven artifacts I have to import so that my development classpath equals the runtime classpath of my WebApp?
I would like to solve dependency conflicts at development time, not at runtime.
You can use the WildFly 16 Bill of Materials (BOM) for that. I'm sure you are well aware of Maven's import feature for artifacts of type POM. Just in case you are not, add these lines to your Maven pom.xml:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.wildfly.bom</groupId>
<artifactId>wildfly-javaee8</artifactId>
<version>16.0.0.Final</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
It enables you to reference most of WildFly's artifacts (or at least the relevant ones) as well as the Java EE 8 specification artifacts. Here's an example:
<dependencies>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-entitymanager</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.jboss.spec.javax.servlet</groupId>
<artifactId>jboss-servlet-api_4.0_spec</artifactId>
<scope>provided</scope>
</dependency>
</dependencies>
<!-- And so on... -->
You still need to list all the dependencies you require though. If you have additional dependencies (not provided by WildFly), you should package them in your WAR or EAR. This way you shouldn't get any conflicts.
Oh, and one more thing, because you mentioned several dependencies, which are WildFly specific (e.g. Weld and Hibernate): Try sticking to Java EE APIs, where possible. It enables you to port your application to other application servers faster, if needed.
Related
This might be a silly question. But I have a doubt, why do we need the following dependency to run EJB in Wildfly?
<dependency>
<groupId>org.jboss.spec.javax.ejb</groupId>
<artifactId>jboss-ejb-api_3.2_spec</artifactId>
<scope>provided</scope>
</dependency>
Do we have something similar which is customized for Wildfly only?
Actually, you just need this maven dependency so your code can compile successfully during maven compile phase. For example, EJB annotations such as #Stateless are provided by it.
I use to declare this maven dependency instead for my Java EE 7 projects, so the whole bunch of JEE specs are available :
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>7.0</version>
<scope>provided</scope>
</dependency>
Finally this maven dependency has to be declared with "provided" scope as you don't need it within your package. Indeed it is already provided by Wildfly, as described in this documentation: Implicit module dependencies for deployments
I have a project that needs a dependency on iText 5.5.2 and on iText 2.1.7 (Primefaces needs this specific version at runtime and won't work with iText 5 due to license issues).
So I have this in my pom.xml:
<dependency>
<groupId>com.itextpdf</groupId>
<artifactId>itextpdf</artifactId>
<version>5.5.2</version>
<scope>compile</scope>
</dependency>
<!-- iText 2.1.7 is necessary at runtime to have the 'Export to PDF' function of Primeface work -->
<!-- It won't conflict with iText 5 as the packages are different -->
<dependency>
<groupId>com.lowagie</groupId>
<artifactId>itext</artifactId>
<version>2.1.7</version>
<scope>runtime</scope>
</dependency>
The problem is that I don't want our developers to be able to import classes from iText 2.1.7 (com.lowagie.* package). I want to force them to use classes from iText 5.5.2 (com.itextpdf.* package).
Although iText 2.1.7 is in 'runtime' scope, Eclipse still adds the jar file in the build path, allowing developers to import the wrong package (com.lowagie instead of com.itextpdf).
Is there a way to exclude it from the build path ?
Unfortunately it seems not to be possible on Eclipse with a normal build, it is a known bug, check Bug 414645 and Bug 376616. Eclipse (m2e) can't properly manage Maven dependencies scope.
However, if you place the runtime dependencies on a profile, then Eclipse will not add them to the classpath (the profile shouldn't be active by default, though). I just tested it on Eclipse Mars and it works perfectly.
Hence, in your case you could add to your POM:
<profiles>
<profile>
<id>runtime</id>
<dependencies>
<dependency>
<groupId>com.lowagie</groupId>
<artifactId>itext</artifactId>
<version>2.1.7</version>
<scope>runtime</scope>
</dependency>
</dependencies>
</profile>
</profiles>
As such, it can't be used to compile on Eclipse. However, your build would then need to use it at runtime, running with -Pruntime in this case.
Although adapting your POM and build to an issue of an IDE might not be ideal, it could be a good compromise to achieve your goal.
Supppose I use spring 4.0 in my pom file and I want to use junit. In that case how can I declare the junit dependency to download the which compatible with the given spring version with out specify any specific junit version. This can be any dependency where I take junit as a example.
In Maven there are two possible matching things. First the dependency management of the artefact itself. spring-core:4.2.0 defines that it depends on commons-codec:1:10. So there is nothing to do for you when you want to also use commons-codec since its already in your classpath. It did not define JUnit so it did not depend on it and should be compatible with all versions.
The second thing is aBOM pom. This is used to package a lot of dependencies together and let the user select the once he needs but the bom defines the versions for you already (and so they should be compatible). Especially spring has some of this bom poms in the repo.
For example spring-framework-bom which packaged everything related to spring which you could use in your app but you will define which parts you need and do not bothering yourself with the version numbers of the sub dependencies.
For example I want to use spring 4.2 and need webmvc the jdbc stuff and something for spring tests. So will define this:
<dependencymanagement>
<dependencies>
<dependency>
<groupid>org.springframework</groupid>
<artifactid>spring-framework-bom</artifactid>
<type>pom</type>
<version>4.2.0.RELEASE</version>
<scope>import</scope>
</dependency>
<dependencies>
</dependencymanagement>
<dependencies>
<dependency>
<groupid>org.springframework</groupid>
<artifactid>spring-webmvc</artifactid>
</dependency>
<dependency>
<groupid>org.springframework</groupid>
<artifactid>spring-jdbc</artifactid>
</dependency>
<dependency>
<groupid>org.springframework</groupid>
<artifactid>spring-test</artifactid>
<scope>test</scope>
</dependency>
</dependencies>
This question doesn't really make sense. If spring 4.0 depends on JUnit (you don't say which spring module you're referring to), JUnit (or any other dependency) will automatically be included in your dependencies, since it will be inherited from the spring 4.0 dependency you have already declared, and the version will match whatever version the Spring module declares in its POM.
However, it seems likely that your particular Spring 4.0 dependency does not depend on JUnit, so in which case you may just pick which ever version is suitable for your requirements.
You can view the dependencies which are currently included in your project (explicit and inherited) by running the following command:
mvn dependency:list
This will trace down the dependency tree and show you all the dependencies which are currently included in your project.
I have several OSGI bundles and WAR packages which use external libraries:
<dependencies>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-web-api</artifactId>
<version>6.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.8.2</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.osgi</groupId>
<artifactId>org.osgi.core</artifactId>
<version>4.2.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.osgi</groupId>
<artifactId>org.osgi.compendium</artifactId>
<version>4.2.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.glassfish</groupId>
<artifactId>osgi-cdi-api</artifactId>
<version>3.1-b41</version>
<type>jar</type>
<scope>provided</scope>
</dependency>
Instead of building the libraries into every OSGI bundle and WAR package is it possible to copy these libraries into /modules directory of the Glassfish server. I suppose that it's possible to use only one copy without any problem?
EDIT
I found that these libraries can be deployed as modules in Glassfish with the command:
[root#Testserver bin]# sh asadmin add-library /opt/primefaces.jar
But then for example in a simple WAR package what I need to modify in order to use Glassfish modules? The WAR package must be configured to use external libraries I suppose?
I don't think the problem is in your war file, but to be sure you can check the MANIFEST file. If the Import-Package headers are correct, there isn't anything you can do from the war file. If that's the case, there must be a way to convince Glassfish to make a module visible to a webapp (I'm no Glassfish expert, sorry).
Otherwise, fix the Import-Package headers (you can do that manually for now).
You can take a look at this section of glassfish documentation, called Module and Application Versions:
http://docs.oracle.com/cd/E26576_01/doc.312/e24929/overview.htm#gkhhv
"Application and module versioning allows multiple versions of the same application to exist in a GlassFish Server domain, which simplifies upgrade and rollback tasks. At most one version of an application or module can be enabled on a server any given time. Versioning provides extensions to tools for deploying, viewing, and managing multiple versions of modules and applications, including the Administration Console and deployment-related asadmin subcommands. Different versions of the same module or application can have the same context root or JNDI name. Use of versioning is optional."
I'm trying to build a Maven based Java EE project on Jenkins, but I'm getting compilation errors. The reason seems to be that the Java EE dependencies that are marked as provided in the POM logically enough aren't downloaded when the project is built.
How can I set up the POM so that the build works in Jenkins, but the EE dependencies aren't included in the WAR file?
My thanks in advance for any input you can provide.
That's strange, AFAIK the dependencies with scope "provided" are simply not placed in the built file, they should however be downloaded. Are you sure your Maven is correctly configured to download dependencies - maybe there's a proxy that's not configured.
Not sure if its the best solution, but you can add EE dependencies with scope "provided", like the example:
<dependency>
<groupId>org.apache.tomcat</groupId>
<artifactId>tomcat-servlet-api</artifactId>
<version>7.0.27</version>
<type>jar</type>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.el</groupId>
<artifactId>javax.el-api</artifactId>
<version>2.2.4</version>
<type>jar</type>
<scope>provided</scope>
</dependency>
Maybe there is a plugin who provides all of them to you, but I'm not sure about that.
Hope that helps