views:

38

answers:

1

Hi,

I am trying to deploy an .ear to Glassfish v3. The .ear is a "Spring" application made up of two modules:

  1. domain.jar (entities, persistence)
  2. service.jar (business logic with spring bean config).

I'm creating the .ear with Maven ear plugin and the resultant dir structure of the .ear is as follows:

  • /APP-INF/lib/domain.jar;service.jar
  • /META-INF/application.xml

I've copied the Spring dist to /glassfish/lib so it is available to all domains on the app server.

UPDATE:

It turns out that commenting out <includeInApplicationXml>true</includeInApplicationXml> from the ear pom.xml will make it deploy. But then my domain.jar is not deployed.

A: 

I don't understand the structure of your EAR. Why are you packaging domain.jar and service.jar (this one contains EJBs right?) as utility JAR under APP-INF/lib? This doesn't look correct to me and I'd expect the following structure instead:

myear
|-- META-INF
|   `-- application.xml
|-- domain.jar
`-- service.jar

Am I missing something about your app?


No, maybe I'm misunderstanding the structure of an ear... I've struggled to find any good articles explaining it - I don't think it helps I'm trying to learn to use Maven too.

The Packaging Applications section of the Java EE tutorials is pretty decent.

I'm quite happy making a multi-module project, but I'm struggling to package it up successfully.

Because I always forget how to use maven-ear-plugin could help... if you really need an EAR.

Pascal Thivent
No, maybe I'm misunderstanding the structure of an ear...I've struggled to find any good articles explaining it - I don't think it helps I'm trying to learn to use Maven too. I'm quite happy making a multi-module project, but I'm struggling to package it up successfully.
pertinky
Thanks Pascal - I'll take a read. I was looking at demoing different flavours of web services from the same project. A persistence module (JPA) with some business logic over the top (EJB3 and Spring), and a suite of web apps (SOAP and rest) exposing the business logic. Unfortunately I believe it would be better to separate them into separate projects to avoid conflicts.
pertinky
Sorted it all - cheers for pointing me in the right direction!
pertinky
@pertinky You're welcome.
Pascal Thivent