Upload
marshall-sherman
View
228
Download
1
Embed Size (px)
Citation preview
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?
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
You should end up with…
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 <build> <plugins> <plugin> <artifactId>maven-ejb-
plugin</artifactId> <configuration>
<ejbVersion>3.0</ejbVersion> <classifier>$
{server.type}</classifier> </configuration> </plugin> </plugins> </build>
<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>
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 - [email protected]
• Resources– Better Builds with Maven– Maven: The Definitive Guide