Apache Maven J 2 EE Front to Back

Apache Maven: J 2 EE Front to Back Jesse Mc. Connell [email protected] org

J 2 EE Application Development by Convention • No laughing matter • People cry everyday because of j 2 ee • 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 J 2 ee • 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 • J 2 EE 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 J 2 EE 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> • <artifact. Id>maven-ejb-plugin</artifact. Id> • <configuration> • <generate. Client>true</generate. Client> • </configuration> • </plugin>

Linking into Build • Validates ejb-jar. xml file existence • Unless you specify ejb. Version 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 | `-- Sample. Action. java |-- resources | |-- images | | `-- sampleimage. jpg | `-- sampleresource `-- webapp |-- WEB-INF | `-- web. xml |-- index. jsp `-- websource. jsp

War Structure and Management • Plugin Example • <plugin> • <group. Id>org. apache. maven. plugins</group. Id> • <artifact. Id>maven-war-plugin</artifact. Id> • <version>2. 0</version> • <configuration> • <webapp. Directory>/sample/servlet/container/deploy/dire ctory</webapp. Directory> • </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> • <artifact. Id>maven-ear-plugin</artifact. Id> • <configuration> • <archive> • <manifest> • <add. Classpath>true</add. Classpath> • </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 dependency. Management, 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 • 300 M 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 Mc. Connell - [email protected] org • Better Builds with Maven, blog at http: //www. devzuz. org