Java – maven ejb project – package with dependencies

jakarta-eejavamaven

Is there a way to pack the dependencies of a maven ejb project in with the final jar?

I typically use a separate ear project and include the ejb as a dependency – it will fill out the lib folder automatically this way. However, this seems a bit wasteful – to have a project just to build the ear.

Right now I have:

<artifactId>projectname</artifactId>
<version>1.0.0-SNAPSHOT</version>
<packaging>ejb</packaging>

        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-ejb-plugin</artifactId>
            <version>2.3</version>
            <configuration>
                <ejbVersion>3.1</ejbVersion>
                <archive>
                    <manifest>
                        <addClasspath>true</addClasspath>

                        <!-- without this, the datetime stamp unique id's will be appended to classpath items -->
                        <!-- see: http://maven.apache.org/shared/maven-archiver/examples/classpath.html#Snapshot -->
                        <useUniqueVersions>false</useUniqueVersions>
                    </manifest>
                </archive>
            </configuration>
        </plugin>

Do I need to set the packaging type to ear? Can I include transitive dependencies in a standalone ejb jar? If I set it to ear, how do I config the ear plugin?

Thanks in advance!

Best Answer

The Maven Shade Plugin can package dependencies in with the JAR. It will extract the classes/resources from all the project's dependencies on package them in with the final JAR.

This should be enough to package all your dependencies:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <version>1.4</version>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>shade</goal>
            </goals>
        </execution>
    </executions>
</plugin>

There are disadvantages to doing this, however.

  • Multiple resources with the same name in different JARs can cause problems (e.g. /META-INF/services/...). You can use Shade's resource transformers, but it can get messy.
  • Not as easy to track what JARs are dependencies in your project once deployed (you'd have to refer back to the POM instead of just looking at the EAR).

Unless you have good reason not to, I'd recommend you stick with building an EAR.

Related Topic