How to package EJB3 with external domain-jar - java

I am facing another problem in my little test-webapp.
I have an EJB module (created via maven-pom) that basically wraps the data-access, so all it does is some DAOs implemented as Stateless-SessionBeans. My domain-model (simple POJOs with JPA2 annotations) is located in another, simple java, project that will be packaged as jar-file.
When I create the enterprise-archive, maven only puts the webapp and the ejb-module into the application.xml and even when I change this manually the ejb-module cannot find the classes from the domain-module at deployment time.
I read something about that an ejb has to have all its dependent jars within its own archive but I cant believe that since this domain-module is used by other projects as well.
How would I package this (or set it up in maven) so my ejb can load classes from an external jar?
thanks

If I remember well, simply generate a manifest with a Class-Path entry in your EJB-JAR:
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ejb-plugin</artifactId>
<configuration>
<ejbVersion>3.0</ejbVersion>
<archive>
<manifest>
<addClasspath>true</addClasspath>
</manifest>
</archive>
</configuration>
</plugin>
...
</plugins>
And add your external jars to the EAR. To do so, declare them as jarModule in the Maven EAR plugin configuration. See modules configuration.

Related

How to package a message-driven bean using Maven?

I want to package a message-driven bean using Maven. The bean has various dependencies (external libraries) that should be packaged with it. In the end, the resulting package should be deployed on an application server (such as Wildfly).
I tried to create multi-module Maven project where I have a module with "ear" packaging that depends on the actual message-driven bean module which uses "jar" packaging (I also tried "ejb" here). However, when the message-driven bean is called it is not able to acccess its dependencies (no NoClassDefFoundError).
The following change to my "ear" pom fixed this issue because the dependencies are now accessible to the message-driven bean.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ear-plugin</artifactId>
<version>2.9.1</version>
<configuration>
<defaultLibBundleDir>lib</defaultLibBundleDir>
</configuration>
</plugin>
</plugins>
</build>
While it basically works now, I feel like I am doing something wrong. Do I really need to change my pom like this? If I have to place the dependencies in the lib directory, why is Maven not doing this by default when building an EAR file.
the EAR/lib folder is the default folder for libraries and every *.jar file inside this folder is automatically loaded by the ear classloader (Java EE 7 Specification)
i think that the EAR/lib folder is come in later specifications of java ee and the maven ear plugin is not updated to this "java ee defaults".
with "defaultLibBundleDir" in maven-ear-plugin all the transitive dependencies are put inside this declared folder. the second is that inside the application.xml folder maven is configuring the "library-directory" element. and this is not required because the "lib" folder is default loaded with the ear classloader.
and this can solved by the setting the maven ear configuration libraryDirectoryMode to NONE
i think it is also best practice to use the fileNameMapping to no-version configuration. this removes the maven versions out of the file names. the maven version is also inside the jar/META-INF/MANIFEST.MF
this is for the jndi name of the modules because the module name came from the jar/war name without the file ending.
your configuration whould look like this:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ear-plugin</artifactId>
<version>2.9.1</version>
<configuration>
<defaultLibBundleDir>lib</defaultLibBundleDir>
<libraryDirectoryMode>NONE</libraryDirectoryMode>
<fileNameMapping>no-version</fileNameMapping>
</configuration>
</plugin>
</plugins>
</build>

How maven jar project works when it is packaged to jar?

I am new to maven. I have created a maven project which will be packaged to JAR. I did clean package then jar is created. When i extracted the same jar, i could not see any dependencies (jars) i added in pom.xml inside the packaged jar. If i give this jar to third party clients how will the code work without any dependent jars ? Please help me how maven manages the jars?
Thanks!
Maven handles dependencies based on how you configure the dependency plugin.
See this reference for a simple example of how to do this.
In this example, the following code configures where your dependencies will end up:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.5.1</version>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<includeGroupIds>log4j</includeGroupIds>
<outputDirectory>${project.build.directory}/dependency-jars/</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
Then this code sets up the classpath for your main jar, which will allow anyone running it to find these dependencies
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.4</version>
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<mainClass>com.mkyong.core.App</mainClass>
<classpathPrefix>dependency-jars/</classpathPrefix>
</manifest>
</archive>
</configuration>
</plugin>
Your other option would be to create a single jar, with all dependencies included, by following this example here
You could distribute the jar and the POM file if you want to try and provide your users with the files in that manner, but they'd need to be able to access your Maven repository where those dependencies are kept.
Core maven doesn't handle this. Maven is a build tool, its work is to build an artifact (a jar in your case). Dependencies you define in your module's pom.xml file are needed to get the code compiled. You'll need maven plugins to do so.
Now, you're asking not about the build, but the distribution of your compiled binaries.
If I understand it should be a lot of jars (your and your dependencies). Alternatively you may distribute the code as a jar + dependencies inside.
Example:
A first case:
If your code resides in module A (say, the code is in packages org.a.*) and depends on some thirdparty (say, log4j, whose classes reside in org.apache.log4j) than you can expect that you jar will only contain the classes of module a and you expect that the log4j will be added by the user of your module automatically (The first case).
A second case:
module a.jar will contain both org.a.* and org.apache.log4j.* classes, everything in the same module.
In general the first approach is more "healthy" and in this case you shouldn't do anything in maven. Maybe your distribution tool/documentation should contain this information.
If someone uses the module a in his/her code like a thirdparty (if you develop a framework or something) and if his/her project is mavenized, than the fact you've defined a dependency on log4j will make the maven to download the log4j as well as your a.jar (In maven notation, this is called "transitive dependencies").
If you're interested in the second case (this can be relevant if you define some "client application", like "jndi client for some server" for example) you might want to take a look on Maven shade plugin
Beware this can lead to dependency hell (what if the application that uses your client also makes use of log4j? what if the log4j-s are of different version)/
Bottom line, you probably want the first approach, think twice before you decide the second approach :)
One more tip, if you just want to download all the dependencies of your module "a" you might want to use maven dependency plugin - type the following in the command prompt
mvn dependency:copy-dependencies
and you'll find all the dependencies in target/dependencies folder
Hope this helps and happy mavening
The simplest solution to the problem is to use the maven-assembly-plugin which can create such jar with dependencies like the following:
<build>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.4</version>
<executions>
<execution>
<id>distro-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
Afterwards you can distribute the created jar xyz-1.0-jar-with-dependencies which contains the defined dependencies.
If you need more control on how the resulting artifact is created or if some files needed to be overwritten etc. you might take a deeper look into maven-shade-plugin

Maven: Export jar with 3rd-party jars added to classpath in manifest

I am developing a Java maven project with Eclipse and want to export a jar that includes all referenced libraries. These referenced libraries fall into one of these two categories:
They are explicit (or implicit) dependencies in the pom.xml
I have some libraries not available as maven artifacts and have put them in /lib (and added them to the build path in Eclipse)
There's the maven-assembly-plugin, which works fine for 1). However, I'm unable to find a maven plugin that also includes non-maven-dependencies, e.g. "all jars in /lib".
Then there's the Eclipse FatJar plugin, which sort of works, but hasn't been updated since 2009, so it seems unmaintained. Also I prefer an export method that I can directly specify in the pom.xml.
Can anyone point me to a maven plugin or the like to export all referenced libraries, including those from case 2) ? That only needs to involve putting them in the jar and referencing them in the manifest's classpath.
Thanks!
I think the best way to handle this is to include your custom libs into a local maven repository. Now you can inlcude your libraries as maven dependencies and you can export all your dependencies specified in your pom with the maven-assembly-plugin.
Here is a tutorial, how to put your libs into a local repository in maven to use it in your pom. http://www.mkyong.com/maven/how-to-include-library-manully-into-maven-local-repository/
And in your pom.xml:
<!-- setup jar manifest to executable with dependencies -->
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
<archive>
<manifest>
<mainClass>your.main.class</mainClass>
</manifest>
</archive>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
This looks like a task for Tycho. It is a set of maven plugins that allows to create eclipse plugins with maven. Tycho considers manifest entries as build dependencies.
However I'm not aware of how to package all those dependencies in a single jar. This may also be conflicting with the osgi spec. But if you wish to ignore osgi you could just try the jar-with-dependencies assembly.

Maven - EJB plugin in parent pom

I've just been asked to work on an existing Java EE web project.
The project contains a lot of modules, some EJB packaged in a EAR and a web part inside a WAR.
What is bothering me is that you actually need 1h30 to compile the whole stuff.
And I found this inside the parent POM betwen the plugin managment part :
<plugin>
<artifactId>maven-ejb-plugin</artifactId>
<configuration>
<ejbVersion>3.0</ejbVersion>
<generateClient>true</generateClient>
<clientIncludes>
<!-- Includes only service interface and business delegate. -->
<clientInclude>**/*Service.class</clientInclude>
<clientInclude>**/*Delegate.class</clientInclude>
<clientInclude>**/ejb/*EJBRemote.class</clientInclude>
</clientIncludes>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
<addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
</manifest>
<manifestEntries>
<Build-Time>${timestamp}</Build-Time>
<Implementation-URL>${project.url}</Implementation-URL>
</manifestEntries>
</archive>
</configuration>
</plugin>
Doesn't this means that every module is being "parsed" by the EJB plugin?
even non-ejb modules?
Thanks.
ps : the parent pom also have some dependancies that also are inside the modules' pom.
I totally forgot this : I found the solution and then the project "only" needed 15 minutes to be compile.
The java version needed to be upgraded, from what I remember there is some kind of bug with maven and java 1.6 version xxxxx.
At the time upgrading to the lastest version of java 1.6 solved the problem (or it was 1.5 I don't remember).

Server can not find class in .ear

I have some problems with my .ear file. The structure of the file is:
app.ear
|-xxx.jar
-yyy.jar
-zzz.jar
-ektorp.jar
-app-ejb.jar
-app-web.war
|-WEB-INF
|-lib
|-xxx.jar
|-yyy.jar
|-zzz.jar
|-ektorp.jar
When I try to deploy my application, I get ClassNotFoundException, with class wihch is in ektorp.jar. This file is used by ejb module.
I also don't know why these jars are doubled? In ear and in war module are the same .jar files.
Ear is built by maven2.
When I try to deploy my application, I get ClassNotFoundException, with class which is in ektorp.jar. This file is used by ejb module.
Does the EJB-JAR reference ektorp.jar in the Class-Path: entry in the manifest (see Packaging EJB 3 Applications for more background on this)? The FAQ explains how you can configure the plugin to generate a Class-Path: entry in the manifest:
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ejb-plugin</artifactId>
<version>2.2.1</version>
...
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
</manifest>
</archive>
</configuration>
...
</plugin>
</plugins>
</build>
...
</project>
Just in case, do you know that you can package EJBs in a .war with Java EE 6 (the difference is that all classes are loaded with the same classloader when using the .war packaging)? If you don't have strong modularization requirements, the .war packaging is simpler.

Categories