Announcement Announcement Module
Collapse
No announcement yet.
EAR creation in Roo Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • EAR creation in Roo

    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.

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

    Comment


    • #3
      Originally posted by andrews View Post
      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)

      Comment


      • #4
        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

        Comment


        • #5
          Originally posted by Stefan Schmidt View Post
          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.

          Comment


          • #6
            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.

            Comment


            • #7
              Originally posted by Stefan Schmidt View Post
              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.

              Comment


              • #8
                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.
                Last edited by Andrew Swan; Sep 5th, 2010, 09:46 PM. Reason: Fixed a seven-month old typo

                Comment


                • #9
                  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

                  Comment


                  • #10
                    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).

                    Comment


                    • #11
                      I totally agree with all of you.

                      In particular, we considered the EJBs useless and we used Spring POJOs instead. It was several years ago (Spring 1.2.8)

                      I could tell you more difficulties that we found regarding Sun recommendations and IBM implementations (“EAR enhanced”, “shared libraries” and other tedious stuff intended to be using at deploying time, that at the end is almost ignored by the production staff)

                      My problem now is that we already have a Java EE application (an EAR running in WAS) that needs to be improved. I wondered whether Roo could create EAR artifacts as part of its process of creating applications.

                      According your answers, now we have a challenge: to maintain the current structure or to create a new application from scratch using Roo.

                      The main difficult is to explain within my organization that EARs will be used no longer (it’s no easy to transfer technical reasons).

                      The main advantage for Roo will be the development time. Directors and chiefs will appreciate a lot spend minutes or hours instead of days when creating CRUD maintenances.

                      I appreciate a lot your answers and I will continue evaluating whether or not the use of Roo will be approved.

                      Javier.
                      P.S.: I could continue bothering you with some context, i.e., the current structure of the application in order to see the difficulties that I need to face.

                      Thanks a lot again.
                      J.

                      Comment


                      • #12
                        Originally posted by jbbarquero View Post
                        I totally agree with all of you.
                        Good, good, keep drinking the kool-aid!

                        My problem now is that we already have a Java EE application (an EAR running in WAS) that needs to be improved. I wondered whether Roo could create EAR artifacts as part of its process of creating applications.

                        According your answers, now we have a challenge: to maintain the current structure or to create a new application from scratch using Roo.
                        In that case you may be interested in these JIRA issues:

                        Comment


                        • #13
                          Originally posted by andrews View Post
                          Okay.

                          Before to drink the Flaming Moe (evidence gathered at the site after the incident indicated that it name was actually Flaming Homer) 'm going to see these JIRA issues.

                          If you remind, we could create new code from scratch (as Darth Vader said, don't underestimate the power of copy-paste)

                          But the current project structure pretends to separate business (both administration and core) from presentation.

                          With presentation I mean the way we provide out our business: web site for human users, web services accessible only for programs and so on (well, actually nothing more)

                          So, we pretend to have an EAR (app.ear) containing:
                          • app-admin (should be a jar containing JPA entities)
                          • app-core (must be a jar with business services [more than accessing DB])
                          • app-web (depends on both admin and core)
                          • app-webservices (publishes part of admin and core)

                          I'm evaluating to create app-web using Roo. How we can create and package the rest of the Java EE application? Can we do that with Roo? At least create separate projects for web, admin and core.

                          Comment


                          • #14
                            Of course I don't pretend to create an EAR in any case. The jar dependencies can be included within the war in the WEB-INF/lib directory.

                            What I need from Roo is the creation of the appropriate projects and artifacts.

                            Or at least, to obtain some Java packages/files (including web artifacts, JUnit and Selenium tests) and then manually managed with maven projects.

                            I'd rather Roo makes the work for me than make it manually, so what I wonder now is whether Roo can manage several web application, at least one for web services, all depending on common business jars.

                            (NOTE: we want separate context root for web applications for humans and web applications for web services)

                            Thanks in advance.

                            Comment


                            • #15
                              We use the WAS and it has no problem installing a war instead of a ear file.

                              As I recall it only needs one extra argument and that is the context root.

                              Comment

                              Working...
                              X