EAR creation in Roo

[jbbarquero]

We need to create Java EE applications (EAR files) in order to deploy them in Java Application Servers (WebSphere Application Server, for instance)

Why Roo doesn't allow within the command line to create a Maven project for creating an EAR file?

We could use the Maven EAR plug-in, but we would like to delegate all the stuff to Roo, as we do with the web projects (WAR files)

Thank you.

[Andrew Swan]

Can't Websphere deploy a WAR file? Or is there some other reason you have to have an EAR file?

[jbbarquero]

Can't Websphere deploy a WAR file? Or is there some other reason you have to have an EAR file?

Thank you for your interest.

It is not a matter of WebSphere, but a requirement of the application to be deployed within the enterprise.

We have to provide an ear with its war and particular business jars (although there are shared libraries like spring or log4j)

[Stefan Schmidt]

Maybe the maven ear plugin can help you here? http://maven.apache.org/plugins/maven-ear-plugin/ I have not used that one though as I have not seen any need for it. Roo generated applications run in all web containers so your requirement is quite unusual.

-Stefan

[jbbarquero]

Maybe the maven ear plugin can help you here? http://maven.apache.org/plugins/maven-ear-plugin/ I have not used that one though as I have not seen any need for it. Roo generated applications run in all web containers so your requirement is quite unusual.

-Stefan

I will try.

However, I'd rather to obtain all the Java artifacts via Roo than using external tools for some Java parts.

The use of EARs is very natural for us.

According SUN, the EAR is the natural way to provide a complete Java EE application.

IBM thinks the same, and all their tools (RAD, WAS...) are oriented to manage EARs (in fact they use EAR enhanced, but we try to avoid them in order to achieve a real WORA application)

Is it totally out of schedule to create EAR artifacts within Roo?

Thank you very much.

[Stefan Schmidt]

Well actually, if you want Roo to create a war file you would use the maven war plugin which is installed for you by Roo in the project pom. So the ear plugin would simply be another maven plugin which you paste into the pom file yourself rather than Roo doing it. That would be about the only difference I can think of.

[jbbarquero]

Well actually, if you want Roo to create a war file you would use the maven war plugin which is installed for you by Roo in the project pom. So the ear plugin would simply be another maven plugin which you paste into the pom file yourself rather than Roo doing it. That would be about the only difference I can think of.

Thank you, I will try.

But I don't know whether the sepparate maven projects for ears, wars, utility jars and so on (including a parent project, packaging pom) could fit the new Roo war project.

[Andrew Swan]

If I understand your requirements correctly, you want to:

• be able to deploy to application servers like Websphere
• WORA
• have the deployment artifact include all required dependencies where possible
• use something that feels "natural"

Given that all the above can be done with WAR files, I still don't understand why you'd want the extra complexity of an EAR file. Having worked with EAR files continuously for the last seven or eight years, they are much more painful to create and use. For example:

• building an EAR file requires a multi-module Maven project, not a single module project like Roo creates; this means:
  
  • you need a master POM, a POM for the EAR file itself, and a POM for each of your artifacts within the EAR file, such as the WAR file and any other JAR files that make up your project; this is much more complex than the single POM required by a WAR-packaged project
  • a number of Maven plugins don't fully support multi-module projects; for example it can be hard to generate application-wide code coverage reports, as the tools want to do this on a per-module basis
  
  
• you can't run an EAR file in a servlet container like Jetty or Tomcat; you need a full-blown app server like JBoss, Websphere, etc. This limits your options both for both deployment and testing (i.e. WARs are closer to WORA than EAR files)
• Roo (which aims to follow solid architectural principles as peer-reviewed within SpringSource) can't create EAR files out of the box (as you know), so for Roo users, as for most of the industry, WAR files are actually more "natural" than EAR files

Sun may indeed say that EAR files are the canonical way to distribute apps, but they say a lot of things that are widely ignored by people with real-world experience. For example, Rod Johnson's rejection of EJBs (and especially EJB entity beans, another Sun recommendation) as the default implementation choice is what led to Spring being created in the first place.

So I don't really get why you'd sign up for all the extra complexity and hassle of EAR files for no apparent gain. The only case in which I can see the need for EAR files is if you use EJBs, in which case make sure you're using them for a really sound business or technical reason. This might involve pushing back on whatever architectural policies are being forced upon you, but you will at least be armed with the information that creating and maintaining EAR files is more complex and therefore more expensive than the much more friendly and flexible WAR file.

[Rod Johnson]

Andrew

I came back to this thread this morning as I didn't have time to post my thoughts yesterday, but you beat me to the punch and eloquently said everything I was going to say :-)

Rgds
Rod

[Ben Alex]

A further consideration is cloud "platform as a service" solutions like Google App Engine, Cloud Foundry and no doubt others all treat WARs as the unit of modularity (not EARs).