Maven Meet Up at Sonatype part II

Brian is now talking about Nexus. There are three types of repositories in Nexus:

• Hosted - the repo lives on disk
• Proxy - this is a proxy to another repository
• Virtual - this allows you to convert between repository formats, say M1 is hosted, you can create a Virtual proxy that converts M1 to M2

You can schedule tasks like cleaning up snapshots. There are RSS feeds for most of the things Nexus does so you know the state of your repo. It will download remote repo indexes. There is no database required for Nexus. Nexus provides a full set of REST APIs to all its features.

The only time you use a repository URL directly in Nexus is when you want to deploy an artifact. With staging & promotion you don't even need to use a repo URL to deploy your artifacts. Why have a stating & promotion strategy? What if you want to test something before actually release it? Enter Nexus stating & promotion. All release deployments occur against a single REST URL in Nexus. The URL can be set once in the corp-pom for all projects, regardless of repository. With templates you can define how Nexus creates this new stating repo. Currently, you can only stage your binary artifacts but not your site artifacts. If you stage something many times and decide only to keep the last build, you'll need to manually remove all but the last site's you generated (this assumes that you don't overwrite your existing site with each release). Since all of Nexus is controlled by REST URLs, you can build your own work flow to control when a repo is promoted or not.

Next up is procurement, how to control what artifacts are available to your projects. Procurement is effectively a firewall that separates the users from another repository (or repo group) in the system. By default, everything is denied.

Sonatype is planning on multiple versions of Nexus: Nexus (open source version, free), Nexus Pro, Nexus Enterprise (HA, Federation, etc.) and Nexus Compliance (legal, etc.).

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>