Maven2: Best practice for Enterprise Project (EAR file)

Question

I am just switching from Ant to Maven and am trying to figure out the best practice to set up a EAR file based Enterprise project?

Let's say I want to create a pretty standard project with a jar file for the EJBs, a WAR file for the Web tier and the encapsulating EAR file, with the corresponding deployment descriptors.

How would I go about it? Create the project with archetypeArtifactId=maven-archetype-webapp as with a war file, and extend from there? What is the best project structure (and POM file example) for this? Where do you stick the ear file related deployment descriptors, etc?

Thanks for any help.

score 99 · Answer 1 · edited Apr 07 '15 at 09:34

You create a new project. The new project is your EAR assembly project which contains your two dependencies for your EJB project and your WAR project.

So you actually have three maven projects here. One EJB. One WAR. One EAR that pulls the two parts together and creates the ear.

Deployment descriptors can be generated by maven, or placed inside the resources directory in the EAR project structure.

The maven-ear-plugin is what you use to configure it, and the documentation is good, but not quite clear if you're still figuring out how maven works in general.

So as an example you might do something like this:

<?xml version="1.0" encoding="utf-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.mycompany</groupId>
  <artifactId>myEar</artifactId>
  <packaging>ear</packaging>
  <name>My EAR</name>

  <build>
    <plugins>
      <plugin>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <source>1.5</source>
          <target>1.5</target>
          <encoding>UTF-8</encoding>
        </configuration>
      </plugin>
      <plugin>
        <artifactId>maven-ear-plugin</artifactId>
        <configuration>
          <version>1.4</version>
          <modules>
            <webModule>
              <groupId>com.mycompany</groupId>
              <artifactId>myWar</artifactId>
              <bundleFileName>myWarNameInTheEar.war</bundleFileName>
              <contextRoot>/myWarConext</contextRoot>
            </webModule>
            <ejbModule>
              <groupId>com.mycompany</groupId>
              <artifactId>myEjb</artifactId>
              <bundleFileName>myEjbNameInTheEar.jar</bundleFileName>
            </ejbModule>
          </modules>
          <displayName>My Ear Name displayed in the App Server</displayName>
          <!-- If I want maven to generate the application.xml, set this to true -->
          <generateApplicationXml>true</generateApplicationXml>
        </configuration>
      </plugin>
      <plugin>
        <artifactId>maven-resources-plugin</artifactId>
        <version>2.3</version>
        <configuration>
          <encoding>UTF-8</encoding>
        </configuration>
      </plugin>
    </plugins>
    <finalName>myEarName</finalName>
  </build>

  <!-- Define the versions of your ear components here -->
  <dependencies>
    <dependency>
      <groupId>com.mycompany</groupId>
      <artifactId>myWar</artifactId>
      <version>1.0-SNAPSHOT</version>
      <type>war</type>
    </dependency>
    <dependency>
      <groupId>com.mycompany</groupId>
      <artifactId>myEjb</artifactId>
      <version>1.0-SNAPSHOT</version>
      <type>ejb</type>
    </dependency>
  </dependencies>
</project>

I found my own answer a year later when I had the same question. Good job self! — Mike Cornell, Jul 21 '10 at 18:23
That pom throws some warnings: `'build.plugins.plugin.version' for org.apache.maven.plugins:maven-ear-plugin is missing` and `'build.plugins.plugin.version' for org.apache.maven.plugins:maven-compiler-plugin is missing`, so you might want to update your otherwise great answer — DiegoAlfonso, Nov 21 '18 at 21:34

score 46 · Answer 2 · answered Jan 08 '12 at 08:23

What helped me a lot was to run the Maven archetype:generate goal and select from one of the archetypes, some of which seem to be updated regularly (in particular JBoss seems to be well maintained).

mvn archetype:generate

Hundreds of archetypes appeared in a numbered list from which to select (519 as of now!). The goal, still running, prompted me to make a selection by entering a number or entering a search string e.g.:

513: remote -> org.xwiki.commons:xwiki-commons-component-archetype
514: remote -> org.xwiki.rendering:xwiki-rendering-archetype-macro
515: remote -> org.zkoss:zk-archetype-component
516: remote -> org.zkoss:zk-archetype-webapp
517: remote -> ru.circumflex:circumflex-archetype (-)
518: remote -> se.vgregion.javg.maven.archetypes:javg-minimal-archetype (-)
Choose a number or apply filter (format: [groupId:]artifactId, case sensitive contains):

I entered the search string "ear," which reduced the list to only 8 items (as of today):

Choose archetype:
1: remote -> org.codehaus.mojo.archetypes:ear-j2ee14 (-)
2: remote -> org.codehaus.mojo.archetypes:ear-javaee6 (-)
3: remote -> org.codehaus.mojo.archetypes:ear-jee5 (-)
4: remote -> org.hibernate:hibernate-search-quickstart (-)
5: remote -> org.jboss.spec.archetypes:jboss-javaee6-ear-webapp 
6: remote -> org.jboss.spec.archetypes:jboss-javaee6-webapp-ear-archetype
7: remote -> org.jboss.spec.archetypes:jboss-javaee6-webapp-ear-archetype-blank
8: remote -> org.ow2.weblab.tools.maven:weblab-archetype-searcher

I selected "org.jboss.spec.archetypes:jboss-javaee6-ear-webapp" (by entering the selection "5" in this example).

Next, the goal asked me to enter the groupId, artifactId, package names, etc., and it then generated the following well-documented example application:

[pgarner@localhost Foo]$ tree
.
|-- Foo-ear
|   `-- pom.xml
|-- Foo-ejb
|   |-- pom.xml
|   `-- src
|       |-- main
|       |   |-- java
|       |   |   `-- com
|       |   |       `-- foo
|       |   |           |-- controller
|       |   |           |   `-- MemberRegistration.java
|       |   |           |-- data
|       |   |           |   `-- MemberListProducer.java
|       |   |           |-- model
|       |   |           |   `-- Member.java
|       |   |           `-- util
|       |   |               `-- Resources.java
|       |   `-- resources
|       |       |-- import.sql
|       |       `-- META-INF
|       |           |-- beans.xml
|       |           `-- persistence.xml
|       `-- test
|           |-- java
|           |   `-- com
|           |       `-- foo
|           |           `-- test
|           |               `-- MemberRegistrationTest.java
|           `-- resources
|-- Foo-web
|   |-- pom.xml
|   `-- src
|       `-- main
|           |-- java
|           |   `-- com
|           |       `-- foo
|           |           `-- rest
|           |               |-- JaxRsActivator.java
|           |               `-- MemberResourceRESTService.java
|           `-- webapp
|               |-- index.html
|               |-- index.xhtml
|               |-- resources
|               |   |-- css
|               |   |   `-- screen.css
|               |   `-- gfx
|               |       |-- banner.png
|               |       `-- logo.png
|               `-- WEB-INF
|                   |-- beans.xml
|                   |-- faces-config.xml
|                   `-- templates
|                       `-- default.xhtml
|-- pom.xml
`-- README.md

32 directories, 23 files

After reading the four POM files, which were well-commented, I had pretty much all the information I needed.

./pom.xml
./Foo-ear/pom.xml
./Foo-ejb/pom.xml
./Foo-web/pom.xml

This works, but it does end up putting a bunch of jboss-specific dependencies into your project, which you may or may not want to clean up after the fact. — Ian McLaird, May 14 '12 at 20:20

score 24 · Answer 3 · answered Jan 26 '15 at 23:55

24

i have made a github repository to show what i think is a good (or best practices) startup project structure...

https://github.com/StefanHeimberg/stackoverflow-1134894

some keywords:

Maven 3
BOM (DependencyManagement of own dependencies)
Parent for all Projects (DependencyManagement from external dependencies and PluginManagement for global Project configuration)
JUnit / Mockito / DBUnit
Clean War project without WEB-INF/lib because dependencies are in EAR/lib folder.
Clean Ear project.
Minimal deployment descriptors for Java EE7
No Local EJB Interface because @LocalBean is sufficient.
Minimal maven configuration through maven user properties
Actual Deployment Descriptors for Servlet 3.1 / EJB 3.2 / JPA 2.1
usage of macker-maven-plugin to check architecture rules
Integration Tests enabled, but skipped. (skipITs=false) useful to enable on CI Build Server

Maven Output:

Reactor Summary:

MyProject - BOM .................................... SUCCESS [  0.494 s]
MyProject - Parent ................................. SUCCESS [  0.330 s]
MyProject - Common ................................. SUCCESS [  3.498 s]
MyProject - Persistence ............................ SUCCESS [  1.045 s]
MyProject - Business ............................... SUCCESS [  1.233 s]
MyProject - Web .................................... SUCCESS [  1.330 s]
MyProject - Application ............................ SUCCESS [  0.679 s]
------------------------------------------------------------------------
BUILD SUCCESS
------------------------------------------------------------------------
Total time: 8.817 s
Finished at: 2015-01-27T00:51:59+01:00
Final Memory: 24M/207M
------------------------------------------------------------------------

answered Jan 26 '15 at 23:55

StefanHeimberg

1,455
13
22

2

I really like your packaging and architectural approach. You should think about packaging your project as a maven archetype. – Jörg Feb 28 '15 at 13:55
2

Very nice solution! I have one question though: why not pack the BOM stuff into the parent project? why the additional layer? – sschober Nov 26 '15 at 07:03
1

cause of separation of concerns. the bom could be imported by other projects. they need only the dependencyManagement of your dependencies and not the dependencyManagement of the dependencies you are using. ok. you can say that if nobody is using your project this additional layer is not nessecary.. but i think that it make sense too... readability. the dependencyManagement of the parent project is not mixed with your dependencies... in a bigger project with > 50 internal maven projects the dependencyManagement inside the parent project could be a mess.. – StefanHeimberg Nov 26 '15 at 07:13
2

another reason is that this is the same structure as documented at http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html. this helps to work in a team where the team members often change becaus it is the "default" documented way. – StefanHeimberg Nov 26 '15 at 07:14
2

BTW. i have created a GitHub project once to show how a multi project setup could be done: https://github.com/StefanHeimberg/maven3-multiapplication-setup (for a company internal discussion) – StefanHeimberg Nov 26 '15 at 07:16
Great answer! I would like to suggest that Gradle be used instead of Maven 3 in first bullet. It has all the benefits of maven and in addition has all the power of Groovy, a Java like programming language, that can be used to write very powerful build scripts. – Farrukh Najmi Dec 29 '16 at 21:19

score 7 · Answer 4 · answered Apr 25 '13 at 10:40

7

NetBeans IDE automatically defines the structure which is almost similar to one suggested by Patrick Garner. For NetBeans users

File->New Project ->In left side select Maven and In right side select Maven Enterprise Application and press Next -> Asks for project names for both war,ejb and settings.

The IDE will automatically create the structure for you.

answered Apr 25 '13 at 10:40

stackOverflow

179
1
2
18

I agree with you, specially when adhering to JEE6 specifications – Sym-Sym Dec 02 '13 at 02:43

score 3 · Answer 5 · answered Jul 22 '10 at 15:02

3

This is a good example of the maven-ear-plugin part.

You can also check the maven archetypes that are available as an example. If you just runt mvn archetype:generate you'll get a list of available archetypes. One of them is

maven-archetype-j2ee-simple

answered Jul 22 '10 at 15:02

hcpl

17,382
7
72
73

10

`maven-archetype-j2ee-simple` seems unnecessarily complex in structure - particularly with modules inside modules, and separate modules for things like logging. I did not understand the rationale behind this structure – Vihung May 16 '12 at 16:16

Roy Truelove · Answer 6 · 2011-04-21T15:14:12.207

2

I've been searching high and low for an end-to-end example of a complete maven-based ear-packaged application and finally stumbled upon this. The instructions say to select option 2 when running through the CLI but for your purposes, use option 1.

edited Apr 21 '11 at 15:14

answered Apr 21 '11 at 15:07

Roy Truelove

22,016
18
111
153

The link throws an unauthorized error. And that's the reason for writing complete solutions instead of relying on links. – Paco Abato Aug 18 '20 at 10:15

Maven2: Best practice for Enterprise Project (EAR file)

6 Answers6

Linked

Related