You are on page 1of 37

Maven 3.

0
Jason van Zyl
SONATYPE
Thursday, March 19th, 2009

Monday, April 20, 2009

Monday, April 20, 2009

Monday, April 20, 2009

XML Monday. April 20. 2009 .

2009 . XML Monday. April 20.

I'm starting to miss XML.NONSTRICT_READ_WRITE )   @EqualsMember   @NotNull   @Valid   @Message( "${msg.CascadeType. April 20. Somehow.MERGE } )   @JoinColumn( name = "PERSON_DETAIL".detail}" )   @XmlElement( name = "person‐detail"..   }   Monday. cascade =    { javax..person. required = true )   public PersonDetail getPersonDetail()   {     return personDetail. an i18n Message manager and EqualsMember.EAGER. 2009 . nullable = false )   @Where( clause = "ACTV_ID = 'T'" )   @Cascade( { CascadeType. javax.DELETE } )   @Cache( usage = CacheConcurrencyStrategy.persistence. /** * This is a method of a Hibernate ORM object which can be serialized via JAXB. * which means this element is a member of the set of fields denoting object * equality.SAVE_UPDATE. CascadeType.CascadeType.persistence. * Also utilizes Hibernate validation.invalid. CascadeType.  * @return related details for this person   */   @ManyToOne( fetch = FetchType.MERGE.PERSIST.

I love Maven! (or I won’t get fed) I love Maven too! Can I have lunch now? Monday. 2009 . April 20.

Monday. 2009 . April 20. I’m going to try Gradle whether you like it or not.

2009 .Monday. April 20.

and has been heavily refactored We hope the code base will be simpler so that more people can get involved Better support for IDEs: all Maven integration in IDEs is actually using 3. April 20. Why Maven 3.x Model Builder Specification: detailed instruction on how the POM is constructed Complete rewrite of the artifact resolution system Monday. code has been reduced. 2009 .0 Maven 2.0 Fewer modules.0 Components lacked degree encapsulation and layering Code base in many places is very difficult to understand and therefore very hard to get more people involved Fundamental problems with artifact resolution system Maven 3.

April 20. 2009 .Monday.

and Igor Fedorenko are essentially working with 3. Oleg Gusakov.x should soon be viable a replacement for 2. but Maven 3.x (trunk) Maven 2.1.x on pretty much a full-time basis Monday.0. Benjamin Bentmann.x.x and the integration tests are telling us so. Shane Isbell.1.1.x moved to Maven 3. I’m sure we’re going to run into many gnarly details but the code is getting much easier to work with and correct with each passing day. 2009 . Brief History Original Maven 2.x Three active branches Maven 2. 2.x work that involved new features became Maven 2.x. Myself.x and 3. April 20.0.0.x I will never talk about delivery dates again.

2009 . Integration Testing An enormous amount of time and energy has gone into improving the the integration tests for Maven. April 20.x that is compatible for most Maven 2.x projects. Monday. The integration tests are the gatekeeper and will let us determine that we have a Maven 3.

x APIs remain viable in 3. The ones that are in our control we can port over to use Mercury. There are several plugins that are using the current artifact resolution code that will not be supported.0 are supported in 3.0. We can support XML. We are relying heavily on our integrations tests right now but as we move forward the work that Shane is doing on the project builder with model-builder will help us to accommodate different versions of a POM. Monday.0. or Intercal. This primarily revolves around plugins that require the old artifact resolution code which is not compatible with the new artifact resolution code at the API level. We don't want people rewriting their plugins. We have managed to keep almost everything backward compatible and we will go so far as to provide an isolated execution environment that can contain older versions of the plugin API so that everything can work. We’ll see as we progress toward 3. We must also ensure that POMs of version 4. The model-builder code has no limitation with respect to formats. and Mercury to create a JRuby-based system. Backward Compatibility We must ensure that plugins and reports written against the Maven 2.0 GA if this is necessary.0. For example someone might build something with the Maven Embedder. and different formats we decide to support. Most people will not be affected and Mercury will be a far better solution.x along with the behavior currently experienced. 2009 . These implementations may find use outside of Maven. JRuby. April 20. We tried to preserve behavior but there’s not much we could do about the APIs. and external users will have to deal with the major version change. The same could be done for Groovy. or any source that anyone can dream up.

Maven The best is yet to come but we really needed to get the house in order first Refactored execution configuration Refactored project builder Refactored plugin manager Refactored lifecycle executor Error & integrity reporting Mercury Maven embedder Plexus/XBean (what are those?) Monday. April 20. 2009 .

Refactored execution configuration Remove Settings from the core and make it a user facing configuration Have one configuration model for request Have one configuration model for session: session takes the request in the constructor and delegates Monday. April 20. 2009 .

2009 . Have ways of transforming between model types Significant cleanup of profiles (uses same build processors) Easier to extend poms Made mercury integration easier Results Versionless parent elements Better version delegation Mixins XML POM format using attributes Scripted POM formats (pom.{rb|groovy|py}) Monday. Specified the rules of construction and have much better unit/IT coverage. April 20. Refactored project builder Hold unmutated (no-interpolation or inheritance) model.

April 20. Basic Module Layout maven-project contains the original APIs for MavenProjectBuilder that core uses maven-project-builder implements maven specific services of model-builder model-builder is general model API Monday. 2009 .

2009 . Refactored plugin manager Generalizing and extracting the plugin manager capabilities and making it available as a library Download artifacts from artifact repositories Create isolated classloaders based on the artifacts downloaded XStream-like configuration mechanism Create isolated execution environments We will use these features to make sure we can support all previous versions of Maven plugins Expression evaluator will become part of the execution environment Monday. April 20.

2009 . but essentially we would be injecting a Map of components with the same role We need specification about ordering and guidelines where extension points could be manipulating the same resources Monday.xml in a WAR Similar to Eclipse extension points. Plugin extension points A plugin extension point must have access to everything in the execution context ExecutionRequest MavenSession Project and its lineage Plugin authors would provide known sites of extension. There may be any number of extensions points depending on what you're doing: For the OSGi example we need an explicit place to modify manifest entries Adding license information could just be something done at an extension point of the packaging plugins Manipulation of web. April 20.

though tools like GMaven are taking the bytecode/ compiler approach. Plugin API Symmetric parameters: input and output Annotations can be used and the javadocs tags will be deprecated Easier to support scripted plugins. Complete separation of reports from the Plugin API Monday. 2009 . April 20.

April 20. I'm hoping to include some better options for bracketing the normal build . We just need a simple way to do some processing at the beginning and end of the lifecycle and much complexity will be reduced in the core.to make aggregator mojos obsolete. and isn't really the right solution for many of the problems it attempts to solve. Aggregator mojos bound to the lifecycle have been deprecated. explicitly . This practice can produce some very strange results.both before. 2009 . and after. Lifecycle extension points Clean extension points for processing at the beginning and end of a lifecycle. but for now they've been deprecated to avoid disrupting backward compatibility. Monday.

2009 . This also applies to plugins that would add resources to a project. Symmetric plugin parameters will be necessary to know how the model might change during execution. You can actually query Maven for the complete execution before it happens. Know about dependencies before executing will also be possible because the new artifact resolution code completely separates the metadata resolution from the artifact resolution. We need to know before hand where a plugin will generate a source directory versus having to execute the lifecycle and examine the compile source roots. Queryable lifecycle The most important change in the embedding environment. Monday. April 20.

April 20. 2009 . Error & integrity reporting Much improved error reporting where we will try to provide links to each identifiable problem we know of Don't allow builds where versions come from non-project sources like local settings and CLI parameters Don't allow builds where versions come from profiles that have to be activated manually Monday.

and Maven repositories are possible Monday. and Jesse from Webtide (the Jetty people) Super fast transport -. Mercury New repository and transport layer Developed by Greg. 2009 . Mercury can be embedded and will allow any domain specific application to retrieve. April 20. Jan. P2.async client with connection pooling and parallelization Atomic downloads and deployments (with Nexus) Full SSL support Full PGP support WebDAV client built-in Full support for ranges using a pseudo boolean solver -.SAT4J Designed. implemented and tested without POMs. and deploy artifacts from any type of Repository: GEMs.

April 20. 2009 . Embedder The embedder is currently being used in all the major IDEs m2eclipse IDEA Netbeans Maven can now be integrated in any build or development tools Monday.

2009 . Plexus/XBean Plexus has a long but quiet history. Annotations are now supported in Plexus thanks to XBean. Started as an offshoot of the Apache Avalon project Started at approximately the same time as Spring but didn’t yet support many features Maven needed XBean is a new DI framework used to provide all the EE injection in OpenEJB and Geronimo. April 20. Plexus will leverage XBean to enable all forms of DI currently known Integration with OSGi Monday.

Tags and categorization in the POM Dependencies Exclude all Properties Parent versions not required General POM extension is possible but still not sure of the implications if we allow this. Monday. The Maven project could encapsulate its release tooling as a mixin so that people could easily reuse that as a capability. Composition over inheritance. 2009 . April 20. POM Elements Mixins: adding capabilities or sets of capabilities very easily. For example you can bring in complete release management capabilities with a mixin.

Here's the example based on what Tycho is currently doing which allows custom components to be used. Netbeans) for adding custom artifact resolvers. This is used in the IDE integration (m2ecipse. and artifact resolver. April 20. In our case with Tycho the packaging is maven-osgi- bundle and that should kick in the set of components that do builds for OSGi bundles. Monday. In the case of Tycho we need a different project builder. Tycho simply has a special set of components that load first before the standard maven components and they override the standard Maven components. 2009 . The embedder has the ContainerCustomizer which allow you to inject new component descriptors. Customizable Components Using a directory and specifying it in the Classworlds configuration. What we ultimately need for Tycho is a way to dynamically pull in a set of components based on the packaging of a project. In this case we need to somehow detect the manifest and then have the custom set of components kick in. We also have another use case in Tycho where we are building OSGi bundles without a POM and actually using a manifest.

MavenCli from plexus.home}/lib/*.core set maven.apache.maven.cli.home default ${user. 2009 . April 20. Dropping in component JARs main is org.jar load ${maven.core] load ${maven.jar Monday.home}/tycho/*.home}/m2 [plexus.

April 20. } Monday.class ).class ).setImplementation( EclipseArtifactResolver. resolverDescriptor.getComponentDescriptor( ArtifactResolver. Using the Container Customizer public void customize( PlexusContainer container ) { ComponentDescriptor resolverDescriptor = container. 2009 .

Project shall be allowed to state which instance of the given toolchain type it requires for the build. If not. Toolchains Plugin denotes what toolchain type it requires for it's operation. The actual instance of the toolchain is passed into the plugin by the infrastructure (using MavenSession). The only change introduced is to use the toolchain in the MavenSession if found. Most current plugins that use JDK for processing.. Shall be user based.m2/toolchains. . if such toolchain instance is not found in user's local setup. So compilation. Monday.. use the maven's JDK instance by default. the build shall fail early. jnlp. project independent. For this purpose a new plugin (maven-toolchain-plugin) is introduced. It is responsible for matching the correct toolchain instances from the user's setup against the requirements of the project and make it available for other plugins to use (in the build context). User defines the toolchain instances that are available in his current setup. need a JDK toolchain instance for example. 2009 . surefire. Therefore making sure that all plugins use jdk15 for example. do as we did so far. stored in $HOME/.xml file. April 20.

0</version> </provides> <configuration> <jdkHome>/home/mkleint/javatools/jdk1.6.6. 2009 .5</version> <vendor>sun</vendor> <id>for_mevenide</id> </provides> <configuration> <jdkHome>/home/mkleint/javatools/jdk</jdkHome> </configuration> </toolchain> <toolchain> <type>jdk</type> <provides> <version>1. Toolchains <toolchains> <toolchain> <type>jdk</type> <provides> <version>1. April 20.0</jdkHome> </configuration> </toolchain> Monday.

//NOI18N } } . Toolchain example /** @component */ private ToolchainManager toolchainManager. if ( tc != null ) { getLog().getToolchainFromBuildContext( "jdk". //get toolchain from context Toolchain tc = toolchainManager.info( "Toolchain in javadoc-plugin: " + tc )... } Monday.. } else { //assign the path to executable from toolchains javadocExecutable = tc.. ignore toolchains. //when the executable to use is explicitly set by user in mojo's parameter. /** * @parameter expression="${session}" * @required * @readonly */ private MavenSession session. session ). if ( javadocExecutable != null) { getLog(). 'javadocExecutable' parameter is set to " + javadocExecutable ).warn( "Toolchains are ignored. 2009 .findTool( "javadoc" ). April 20. public void execute() { .

Incremental build support We needed better integration with m2eclipse. 2009 . It is possible to hack around Maven core and we have done this right now as part of this experiment. but it seems to be working work. We have modified: maven-resources-plugin: generated resources modello-maven-plugin: generated sources plexus-component-metadata: annotation processing producing resources Monday. So far we have only modified three plugins so. but it needs to be fixed correctly in Maven. April 20.

This approach would also be useful for quality reporting systems like Sonar. This is where we could completely mesh with Hudson so that Maven reports could be used to produce useful trending information.x will not be coupled to Doxia. April 20. Extensible reporting Create a completely separate system for reporting. Different reporting solutions should be supported: not just the maven-site-plugin solution which is completely coupled to Doxia. 2009 . Maven 3. A data production model for build information is more useful then the document production model. It should not be part of Maven’s core and should really live in its own world. An entirely separate execution environment is required for reporting. Monday.

new r.apache. April 20.MavenEmbedder' include_class 'org.execute( r ).apache.io.new(configuration) r = DefaultMavenExecutionRequest. end end m = Maven.embedder.maven.new( ["install"] ).DefaultConfiguration' include_class 'org.DefaultMavenExecutionRequest' def run configuration = DefaultConfiguration. 2009 .maven.execution. Maven4R class Maven def initialize goals @goals = goals end include_class 'java.maven.new maven = MavenEmbedder.embedder.apache.setGoals( @goals ) result = maven.run Monday.File' include_class 'org.