380 likes | 566 Views
Juggling Java EE with Enterprise Apache Maven. Jesse McConnell - jmcconnell@apache.org. 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. Is this you?.
E N D
Juggling Java EE with Enterprise Apache Maven Jesse McConnell - jmcconnell@apache.org
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
Java EE Application Development by Convention • No laughing matter • People cry everyday because of java ee • Maven can help keep crying to a minimum • hopefully • Planning is key
Components of Java EE • Enterprise Java Beans’s • maven-ejb-plugin • V. 2 and 3 specs • Web Services • axistools-maven-plugin • cxf-maven-plugin • others • Web Archives (Wars) • maven-war-plugin • Enterprise Archives (Ears) • maven-ear-plugin
Maven Lifecycle • Supported since the beginning with maven 2 • Java EE artifact linkage 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 Java 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> <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. • Otherwise test when in ear and under typical ejb conditions
Web Service Structures and Management • No strict lifecycle phase • No strict directory layout • Depends on web service architecture in use • xfire -> CXF, Axis, etc • Code generation components • wsdl2java • java2wsdl
Linking into Build • Consider services, clients, resource libraries • Common project layout • Annotations of services • All kind of 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>/container/deploy/dir</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 shared security and user management bits
Linking into Build • Dependency management scoping is key • Dig into your war file and see what is in there • Don’t be afraid, its doesn’t bite • <scope>provided</scope> can be your friend • Other Options: • <warSourceExcludes>WEB-INF/lib/*.jar</warSourceExcludes>
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
War Overlay I - Clean <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-clean-plugin</artifactId> <version>2.1.1</version> <!-- This configuration is added to cleanup from war:inplace --> <configuration> <filesets> <fileset> <directory>${basedir}/src/main/webapp</directory> <includes> <include>images/redback</include> <!-- Images from other wars --> <include>template/</include> <!-- validation.js --> <include>template/redback</include> <!-- Templates from other wars --> <include>WEB-INF/classes</include> <!-- Classes and Resources from other wars --> <include>WEB-INF/lib</include> </includes> </fileset> </filesets> </configuration> </plugin>
War Overlay II - War <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-war-plugin</artifactId> <version>2.0.1</version> <configuration> <archiveClasses>false</archiveClasses> <dependentWarExcludes>META-INF/**,WEB-INF/web.xml,WEB-INF/classes/xwork.xml,WEB-INF/lib/** </dependentWarExcludes> </configuration> <executions> <execution> <phase>compile</phase> <goals> <!-- Needed to get the plexus-security war overlay to do its thing before jetty:run --> <goal>inplace</goal> </goals> </execution> </executions> </plugin>
Jetty Configuration <plugin> <groupId>org.mortbay.jetty</groupId> <artifactId>maven-jetty-plugin</artifactId> <version>6.1.0</version> <configuration> <scanIntervalSeconds>10</scanIntervalSeconds> <contextPath>/</contextPath> <jettyEnvXml>${basedir}/src/jetty-env.xml</jettyEnvXml> <connectors> <connector implementation="org.mortbay.jetty.nio.SelectChannelConnector"> <port>9090</port> <maxIdleTime>60000</maxIdleTime> </connector> </connectors> </configuration> <dependencies> <dependency> <groupId>org.apache.derby</groupId> <artifactId>derby</artifactId> <version>10.1.3.1</version> </dependency> </dependencies> </plugin> <systemProperties> <systemProperty> <name>appserver.base</name> <value>${project.build.directory}/appserver-base</value> </systemProperty> <systemProperty> <name>appserver.home</name> <value>${project.build.directory}/appserver-home</value> </systemProperty> <systemProperty> <name>derby.system.home</name> <value>${project.build.directory}/appserver-base/logs</value> </systemProperty> </systemProperties>
Testing Wars I • jetty-maven-plugin for ‘click testing’ • mvn jetty:run • Integration testing a bit more involved…
TestingWars II • generate-resources • dependency-maven-plugin • Unzip the webapp • Prepare provided dependencies • package • maven-antrun-plugin • Copy container configuration • Copy provided dependencies • pre-integration-test • selenium-maven-plugin • Start server • cargo-maven2-plugin • Start container • integration-test • maven-antrun-plugin • Check continuum started • maven-surefire-plugin • Run tests • Post-integration-test • Cargo-maven2-plugin • Stop container
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
Supported Ear Modules • ejb3Module - ejb3 (Enterprise Java Bean version 3) • ejbClientModule - ejb-client (Enterprise Java Bean Client) • ejbModule - ejb (Enterprise Java Bean) • jarModule - jar (Java Archive) • harModule - har (Hibernate Archive) • parModule - par (Plexus Archive) • rarModule - rar (Resource Adapter Archive) • sarModule - sar (JBoss Service Archive) • webModule - war (Web Application Archive) • wsrModule - wsr (JBoss Web Service Archive)
Testing Ears • Functionally the same kind of process as the war integration testing • use cargo • Bind start app server to pre-integration-test phase • Start Selenium server • Run any surefire tests • Bind stop app server to post-integration-test
Scoping Ear Dependencies • Learn Dependency Management in parent poms • Love it • Plan for ear deployment, 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 - cargo.codehaus.org • Supported containers • Geronimo 1.x - geronimo1x • JBoss 3.x, 4.x - jboss3x, jboss4x • Jetty 4.x, 5.x, 6.x - jetty4x, jetty5x, jetty6x • jo! 1.x - jo1x • OC4J 9.x - oc4j9x • Orion 1.x, 2.x - orion1x, orion2x • Resin 2.x, 3.x - resin2x, resin3x • Tomcat 3.x, 4.x, 5.x - tomcat3x, tomcat4x, tomcat5x • WebLogic 8.x - weblogic8x • Maven2 plugin support • Deployment area largely untargeted by maven conventions • Hard to standardize in real world
Tips and Tricks • Got a 300meg ear file? • Check the scoping • Pull apart the artifacts and look for jar duplication • Understand Java EE classloaders
Tips and Tricks II <profiles> <profile> <id>prod</id> <properties> <ejb.jdbc.url>jdbc:odbc:prod;UID=prod;PWD=p4ssw0rd</ejb.jdbc.url> <server.type>prod</server.type> </properties> </profile> <profile> <id>test</id> <properties> <ejb.jdbc.url>jdbc:odbc:test;UID=test;PWD=p4ssw0rd</ejb.jdbc.url> <server.type>test</server.type> </properties> </profile> <profile> <id>dev</id> <properties> <ejb.jdbc.url>jdbc:derby:dev</ejb.jdbc.url> <server.type>dev</server.type> </properties> </profile> </profiles> <build> <plugins> <plugin> <artifactId>maven-ejb-plugin</artifactId> <configuration> <ejbVersion>3.0</ejbVersion> <classifier>${server.type}</classifier> </configuration> </plugin> </plugins> </build>
Using Archetypes • maven-archetype-j2ee-simple • Sample aggregate project • Geronimo sample archetypes • Many jetty sample archetypes • http://www.webtide.com/resources.jsp
Questions? • Jesse McConnell - jmcconnell@apache.org • Resources • Better Builds with Maven • Maven: The Definitive Guide