Thursday, March 19, 2009

Maven Meet Up at Sonatype part I

Maven 3.0 will be fixing what we've learned in Maven 1.0 and 2.0. Layered repository, at the command line there is really only one repo, but in an env like Eclipse there are many repositories, other projects, so Maven 3.0 will have the concept of layered repositories. Jason said they have a lot of integration tests to ensure the backwards compatibility of Maven 3.0 with Maven 2.0. Personally, I hope it goes better than the Maven 2.0.8 to Maven 2.0.9 transition.

Plugin extension points, something borrowed from Eclipse, plugins will have extension points. This way you can extend a plugin without having to hack it. Plugins will also be able to tell Maven, here are my output directories, this way in Eclipse Maven will not need to run all the plugins to get their generated source dirs. This would be a big improvement.

Mercury is the new repository and transport layer for Maven. Why Mercury? Maven 2 has inaccurate conflict resolution, based on custom graph walking algorithm, hard to replace, API is too complex. The resolution mechanism is too coupled to Plexus, cannot use it from other environments. Mercury is a general purpose library for artifact and repository management. ArtifactMetadata - artifact comprehension info, not only do you need GAV (GroupId, ArtifactId, Version) but you also need classifier, type, etc. Mercury repos can be local or remote, readable or read/write, this helps optimize Mercury. It also supports global exclusions.

Mercury has it's own metadata cache to cache metadata for remove repositories. The new transport layer is a Jetty client, supports connection multiplexing (NIO), concurrent connections, SSL support. Webtide added stream verification , proxy support and authentication.

Oleg is now talking about Sonatype Proviso, a tool for updating binaries (e.g. Maven). Mercury Runner is a side project for Oleg, it gives you a way to run an application without defining a classpath. Attribute based resolution, we don't just care about a JAR, or it's version, we actually want to know about it's quality, etc. Like this:

<project>
...
<version>1.2</version>
...
<attributes>
  <servletApi>3.0</servletApi>
  <coverage:pmd>80</coverage:pmd>
  <quality>alpha</quality>
</attributes>
...
<project>
<dependency>
 <servletApi>[2.5,)</servletApi>
 <coverage:pmd>[80,)</coverage:pmd>
</dependency>

No comments: