Maven 2

1. The Maven Team @ Apache Maven 2

2. Overview • What's new in Maven 2.0 • Maven 2.0 and Ant • ... and anything else you'd like to know about

3. Maven 2.0 • Is a complete rewrite from Maven 1.0/1.1 • Scheduled for beta testing in July, final release in August • Built around reusable libraries: • Artifact code used in Ant tasks • Wagon, SCM and project loading being used in Maven 1.1

4. Why rewrite Maven for 2.0? • Started parallel development in early 2003, well before Maven 1.0 final! • More consistent definition of all parts of the system • Architecture supports features and that the original couldn't • Faster, lighter, smaller - embeddable • Making it simpler to use required reworking many core concepts

5. Maven 2.0 Architecture

6. Maven 2.0 Architecture - Plexus • Based on Plexus – an IoC container supporting component oriented programming (COP) encouraging a clear Separation of Concerns (SoC) • Plugins are handled as Plexus components though plugins have no direct dependency on Plexus

7. Maven 2.0 Component Architecture

8. Maven 2.0 New Features (alpha-3) • Enhanced dependency support • Build life cycle • Unified project file • Enhanced plug-in support • Multi-module project support • Site and documentation enhancements • Release management • Archetypes - project templates • Build Profiles

9. Adding Dependencies • Declaration will download it, add it to the classpaths, bundle it into the resulting distribution if appropriate, etc. • Main hurdle is non-redistributable artifacts – manual installation • Now transitive – dependencies of dependencies <dependencies> <dependency> <groupId>org.apache.maven.wagon</groupId> <artifactId>wagon-provider-api</artifactId> <version>1.0-alpha-3</version> </dependency> </dependencies>

10. Transitive Dependencies • Always enabled in Maven 2.0 • Don't need to declare dependencies of dependencies yourself • Frequently requested, but has more consequences than often realised... • Version conflicts • Unwanted dependencies • Bad published meta data – report at http://jira.codehaus.org/browse/MEV • Not a hard problem with good data

11. Dependency Scope • compile (default), runtime, test, provided • Control classpath and distribution bundling • Helpful for transitive dependencies (don't get test transitively) • Only need to specify one – others may be implied

12. Controlling Transitive Dependencies • Filter out dependencies • Preferably dependency would be split into isolated pieces, with one POM to aggregate back if needed • E.g. Velocity “depends” on JDBC, but only in some conditions <dependency> <groupId>org.apache.maven.wagon</groupId> <artifactId>wagon-provider-api</artifactId> <version>1.0-alpha-3</version> <exclusions> <exclusion> <groupId>jdbc</groupId> <artifactId>jdbc</artifactId> </exclusion> </exclusions> </dependency>

13. Snapshot Handling • Deploying to a shared repository gives a version with a time stamp and build # • Don’t need to update dependency version to get updated builds • Updates daily, on-demand, or at a particular interval • Developers can get access to co-workers changes earlier without the need to update and build

14. Build Life cycle • Builds in Maven follow a pattern • Ensures developers moving between projects do not need to learn new processes

15. Build Life cycle • Plugins can augment the build life cycle • For example: • JAXB could register an XSD to Java goal in generate-sources, then add it to the compilation list • Xdoclet could register a goal to create a Hibernate mapping in process-resources. • The builder still only needs to know to use m2 package • Replaces use of preGoal from Maven 1

16. Unified Project File • Self contained, and no file system references making it usable from the repository • project.properties and maven.xml replaced by custom plugins and configuration • parent element replaces extend <parent> <groupId>org.apache.maven</groupId> <artifactId>maven</artifactId> </parent>

17. Configuring Plugins • Configure how your project is built • In Maven 1, project.properties file • Example: compile with JDK 5.0 options <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.5</source> <target>1.5</target> </configuration> </plugin> </plugins> </build>

18. On-demand Features • Plugins can be requested on-demand from the command line • In Maven 1, this required manual installation • For example, idea:idea will generate an IDEA project file without modifications to your project

19. Plugin Version Discovery • Can opt not to declare a plugin version in your project • Will regularly check for a new release, and download it if desired • Users can opt to get prompted for new releases of plugins • Release tool will record the active version for reproducible builds

20. Plugin Languages • Java, Beanshell, Marmalade • Java is the most common • Beanshell is new, useful for rapid prototyping • Marmalade is primarily to ease porting of Jelly-based plugins, and to make available Ant tasks in an XML syntax • Can support others with a small amount of work if there is demand • For example: Jython, Groovy, JRuby

21. Java Plugin import org.apache.maven.plugin.AbstractMojo; import org.apache.maven.plugin.MojoExecutionException; ... /** * Goal which cleans the build. * @goal touch * @phase process-sources */ public class CoreItMojo extends AbstractMojo { /** @parameter expression="${project.build.directory}" * @required */ private File outputDirectory; /** Whether it is enabled. * @parameter */ private boolean enabled; public void execute() throws MojoExecutionException { if ( enabled ) { getLog().info( “Path is ” + outputDirectory ); } } }

22. Beanshell Plugin /** * Beanshell mojo integration test. * @goal it0020 */ import org.apache.maven.plugin.Mojo; import org.apache.maven.script.beanshell.BeanshellMojoAdapter; import org.codehaus.plexus.util.FileUtils; execute() { logger.info( "Executing it0020..." ); print( "info level?" ); FileUtils.fileWrite( outDir.getAbsolutePath() + "/out.txt", "This is a Beanshell test" ); } /** * Output directory for files. * * @parameter expression="${project.build.directory}" type="java.io.File" * @required */ setOutDir( file ) { outDir = file; } return new BeanshellMojoAdapter( (Mojo) this, this.interpreter );

23. Marmalade <mojo xmlns="marmalade:mojo"> <metadata> <goal>it0015</goal> <description> Output a file with specified contents to [outDir] </description> <parameters> <parameter> <name>outDir</name> <type>java.lang.String</type> <expression>${project.build.directory}</expression> <description>Output directory for files.</description> </parameter> </parameters> </metadata> <execute> <it0015:writeFile xmlns:it0015="marmalade:it0015" path="${outDir}/out.txt"> This is a test. </it0015:writeFile> </execute> </mojo>

24. Multiple Modules • Maven 2 natively deals with multi-module builds • A module refers to another project in the build tree • Goals are performed on all found modules by default, so m2 install will perform an install for all found modules • Modules can in turn have modules <modules> <module>wagon-provider-api</module> <module>wagon-providers</module> </module>

25. Site and Documentation • A lot faster than previously • Accepts several input formats • Almost Plain Text (Wiki like) • Xdoc (Maven 1.0 compatible) • FAQ (Maven 1.0 compatible) • Docbook • Presently outputs XHTML, Xdoc, Docbook, Latex and RTF • PDF also planned

26. Example APT Document ------ Generating a Site ------ Brett Porter ------ 13 May 2005 ------ Building a Site * Creating Content The first step to creating your site is to create some content. In Maven 2.0, the site content is separated by format, as there are several available. ------------------- +- src/ +- site/ +- apt/ | +- index.apt +- site.xml -------------------- The Xdoc format is the same as {{{http://maven.apache.org/using/site.html} used in Maven 1.0}}. However, <<<navigation.xml>>> has been replaced by the site descriptor (see below).

27. Example APT Document

28. Release Assistance • Improvement on the tasks from the SCM plugin in Maven 1.0 • Resolves information in the project to make the release reproducible • Updates the version information, commits and tags a release • Does a clean checkout and builds the release • Can be in the same environment, or a dedicated known build environment

29. Project Archetypes • m2 archetype:create • Generates a template project for you • Currently archetypes for: • JAR/WAR • Site • Java and Marmalade Plugins • Can easily create your own archetypes • Uses Velocity • Downloaded from the repository so they are easily shared

30. Build Profiles • Change the build depending on the environment • Dependencies, repositories, plugins and configuration • Trigger by operating system, JDK, extistence of software, and so on, as well as command line parameter • Per user or per project • Used to set up standard environments: • Development, Test, QA and Production

31. Maven 2.0 Features Coming (July) • More on dependency mediation • Other languages (maybe beyond 2.0)

32. Dependency Mediation • Allows specification of a range of versions for a dependency • Maven will help resolve the best version available • Techniques for handling conflicts • Fail, Newest, Nearest • Release tool fills in versions later <dependency> <groupId>jaxb</groupId> <artifactId>jaxb-api</artifactId> <version>[1.0.1,)</version> </dependency>

33. Support for Other Languages • Being implemented as plugins • Currently have seen work on a C# compiler, and plan to support C/C++ environments on Unix and Windows • May not be available at Maven 2.0 final release

34. Moving from Ant to Maven 2 • Identify sections of build.xml that are standard functionality • Build Maven 2 projects from scratch • Use m2 ant:ant to generate and use from master Ant script • Create Maven plugins for custom functionality, wrap them as Ant tasks • If Ant already works fine for you, you can still use some Maven features from Ant 1.6 today

35. Using Maven 2 From Ant • Currently exposes the dependency and artifact handling as Ant tasks • Ant 1.7 will utilise the artifact antlib for dependency management • Download dependencies (all features) • Share a local Maven repository • Install and deploy artifacts to a repository • Expose a POM as Ant properties

36. The Artifact Antlib <project ... xmlns:artifact="antlib:org.apache.maven.artifact.ant"> <target name="..."> <artifact:localRepository id="local.repository" location="${basedir}/target/local-repo" /> <artifact:dependencies pathId="dependency.classpath" filesetId="dependency.fileset"> <dependency groupId="org.apache.maven.wagon" artifactId="wagon-provider-test" version="1.0-alpha-2"/> <dependency groupId="org.codehaus.modello" artifactId="modello-core" version="1.0-alpha-2-SNAPSHOT"/> <localRepository refid="local.repository"/> </artifact:dependencies> <!-- Can reuse POM --> <artifact:pom id=“maven.project” file=“pom.xml”/> <artifact:dependencies filesetId=“pom.dependencies”> <pom refid=“maven.project”/> </artifact:dependencies> <!-- Access to POM as properties --> <echo>Now building ${maven.project.name}</echo> ...

37. The Artifact Antlib ... <artifact:remoteRepository id="deploy.repository" url="file://${basedir}/target/deployment-repo" layout="legacy"/> <artifact:install file="target/maven-artifact-ant-2.0-SNAPSHOT.jar"> <localRepository refid="local.repository"/> <pom refid="maven.project"/> </artifact:install> <artifact:deploy file="target/maven-artifact-ant-2.0-SNAPSHOT.jar"> <localRepository refid="local.repository"/> <remoteRepository url="scp://localhost/tmp/deployment-repo"> <authentication username="brett" privateKey="${user.home}/.ssh/id_dsa"/> </remoteRepository> <pom refid="maven.project"/> </artifact:deploy>

38. Maven and the IDE • MevenIDE project • Started out with NetBeans, Eclipse • Relatively new Jbuilder and IDEA plugins • Shared base code • Changes reflect in project and IDE • Planning support for embedded Maven 2 and remote Continuum • Independent of the Maven project • Maven has project generation for several IDEs for one way creation

39. Resources • Maven site and lists • http://maven.apache.org/ • Maven Blogs • http://www.mavenblogs.com/

40. Getting Involved • As with any open source project, there are several ways you can get involved • Join the mailing list and answer other user's questions • Report bugs, feature requests and other issues in the issue tracking application. • Submit patches to reported issues (both those you find, or that others have filed)

41. Questions? • Thanks for listening!