460 likes | 736 Vues
Apache Maven: J2EE Front to Back. Jesse McConnell - jmcconnell@apache.org. J2EE Application Development by Convention. No laughing matter People cry everyday because of j2ee Maven can help keep crying to a minimum hopefully. Who Am I?. On Maven PMC Active in Continuum Some maven plugins
E N D
Apache Maven:J2EE Front to Back Jesse McConnell - jmcconnell@apache.org
J2EE Application Development by Convention • No laughing matter • People cry everyday because of j2ee • Maven can help keep crying to a minimum • hopefully
Who Am I? • On Maven PMC • Active in Continuum • Some maven plugins • Some mojo plugins @ codehaus • Axistools-maven-plugin - don’t hold that against me…pls • Redback @ codehaus
Components of J2ee • EJB’s • Maven-ejb-plugin • Web Services • Axistools-maven-plugin • Xfire-maven-plugin • others • Web Archives (Wars) • Maven-war-plugin • Enterprise Archives (Ears) • Maven-ear-plugin
Maven Lifecycle • Supported since the beginning with maven 2 • J2EE artifact lifecycle is managed through dependencies • Artifact construction dictated by <type/>
Understanding Structure in Maven • Follow Conventions • Archiva and Continuum are good example Web Applications • Redback is security overlay packaged as a Web Application and overlaid
Library Code • Understanding the final goal and scoping dependencies appropriately. • That means…understand J2EE classloaders • Understand your Container • Like to think they are all interchangeable • Can be harder in practice
EJB Structure and Management • <packaging>ejb</packaging> • Directory Layout • |-- pom.xml • `-- src • `-- main • `-- resources • `-- META-INF • `-- ejb-jar.xml
EJB Structure and Management • Plugin Example • <plugin> • <artifactId>maven-ejb-plugin</artifactId> • <configuration> • <generateClient>true</generateClient> • </configuration> • </plugin>
Linking into Build • Validates ejb-jar.xml file existence • Unless you specify ejbVersion 3.0
Testing EJB Code • Best bet is testing modularly like with normal junit testing.
Web Service Structures and Management • No strict lifecycle phase • No strict directory layout • Depends on web service architecture in use • Xfire -> CXF, Axis, etc
Linking into Build • Consider services, clients, resource libraries • Common project layout • Annotations of services • All kinda implementation specific • Real deal is testing them
Testing Web Services • Can be hard to test directly • Client testing against established servers begs irreproducibility • Test by deploying services to embedded jetty and running client code
War Structure and Management • <packaging>war</packaging> • Directory Layout • |-- pom.xml • `-- src • `-- main • |-- java • | `-- com • | `-- example • | `-- projects • | `-- SampleAction.java • |-- resources • | |-- images • | | `-- sampleimage.jpg • | `-- sampleresource • `-- webapp • |-- WEB-INF • | `-- web.xml • |-- index.jsp • `-- jsp • `-- websource.jsp
War Structure and Management • Plugin Example • <plugin> • <groupId>org.apache.maven.plugins</groupId> • <artifactId>maven-war-plugin</artifactId> • <version>2.0</version> • <configuration> • <webappDirectory>/sample/servlet/container/deploy/directory</webappDirectory> • </configuration> • </plugin>
War Overlay • Often handy to build component oriented wars. • Overlay multiple war files to create actual war file. • Continuum and Archiva do this is redback for common security and user management
Linking into Build • Dependency management scoping is key • Dig into your war file and see what is in there • <scope>provided</scope> can be your friend
Three different usages • War:war - standard war creation • War:exploded - builds out war in exploded format in target dir • War:inplace - builds out webapp in src/main/webapp • Dependency Management scoping key for war usability
Testing Wars • Deploy via Jetty-maven-plugin during development • Selenium-maven-plugin for automated testing
Scoping War Dependencies • Two Approaches, different scoping • Deploying Wars • Integrating into Ears
Ear Structure and Management • Directory Layout • No specific directories required • Dependencies are key to ear files • Automatic application.xml creation • MANIFEST.MF Creation
Ear Structure and Management • Plugin Example • <plugin> • <artifactId>maven-ear-plugin</artifactId> • <configuration> • <archive> • <manifest> • <addClasspath>true</addClasspath> • </manifest> • </archive> • </configuration> • </plugin>
Linking into Build • Just do it… • Then triage. • Primary recommendation, keep your project modular • Test your modules • Use ear module as simply the aggregation of the project • packaging
Testing Ears • No easy peasy way • Have to deploy somewhere • Have to start something • Have to access it • Non-trivial task • Best off testing your stuff modularly before you get to this point.
Scoping Ear Dependencies • Learn Dependency Management in parent poms • Love it • Plan for ear deployement, scope things that are used by multiple war and ejb’s as provided or test in those poms • Scope for inclusion in ear, leave versioning to the dependencyManagement, its why it is there
Application Deployment Options • Cargo-maven-plugin • Largely area untargeted by maven conventions • Hard to standardize in real world
Tips and Tricks • 300M Ear file Check the Scoping Pull apart the artifacts and look for jar duplication Understand those classloaders
Using Archetypes Example of Quick Project Startup
Questions? • Jesse McConnell - jmcconnell@apache.org • Better Builds with Maven, blog at http://www.devzuz.org