In the previous article, we demonstrated one way of running integration tests with Maven. In this article, we will demonstrate how to measure the test coverage of both integration and unit tests.
Once you decide to install a Repository Manager, the next decision is how to setup your repositories, particularly if you have multiple teams sharing the same instance. Nexus is very flexible in this area and supports a variety of configurations. I’ll first describe the options and then discuss the thought process used to decide what makes sense for your organization.
The first and most obvious way to support multiple teams is to configure a pair of repositories per team (one release, one snapshot). The team is then given the appropriate C.R.U.D. permissions and they are able to use the system for their artifacts.
Our http://oss.sonatype.org instance is for the most part configured in this manner, where each project like Jetty has their own repositories separate from everyone else.
Another option is to have a single (or a few) pair of Release/Snapshot repositories for your entire organization. In this case, the access is controlled by a mechanism we call “Repository Targets.”
Simply put, a Repository Target is a way to manage a set of artifacts based on their paths. A Repository Target is simply a list of regular expressions and a Name. For example, a Repo Target for Maven would be “./org/apache/maven/. and Nexus OSS would be “./org/sonatype/nexus/.“
Note: while it is most common to manage artifacts based on the path of their groupId, the Regular Expression is matched against the entire path, and so it is also possible, for example, to define “Sources” as “.*-sources.jar” … it’s also worth noting that Repository Targets are not mutually exclusive. It is perfectly valid for a given path to be contained by multiple targets.
In this model, you would create a Repo Target for each project in your system. You are then able to take the Repo Target and associate it with one or more Repositories or Groups in your system. When you do this, new, specific, C.R.U.D. privileges are created. For example, I could take the Maven Repo target, associate it with my Release and Snapshot repository, and now I get privileges I can assign to Create, Read, Update, Delete “Maven” (./org/apache/maven/.) artifacts in my Release and Snapshot repositories.
This method is used to manage the http://repository.apache.org instance, where we have just one Release and Snapshot repository and each project team gets permissions to their artifacts based on the path.
First of all, these choices aren’t mutually exclusive. In fact, the first option builds upon the default Repository Target of “.*” which simply gives you access to all artifacts regardless of the path. You still associate the default Repo Target with specific repositories to create the assignable privileges
In general, it’s my opinion that fewer repositories will scale better and are easier to manage. It’s also easier to start off with a single pair of repos, with the default “All M2″ (.*) target and simply refine the permissions as you scale. Most things that are configured per repository (Cache, Storage location, Snapshot purging, etc) will generally be applicable for all projects, so this mode avoids the duplication of these tasks. Since everything will be stored together in a single folder on disk, it makes backups easier as well.
The reasons why you would want multiple sets of repositories is essentially the opposite of above: If you need different expiration, Snapshot purging or storage folders, then a single shared repo won’t work. Replication and failover strategies may also make this method easier to support. If you absolutely must maintain total separation between Project teams, ie they can’t read each other’s artifacts, then this solution might be more applicable as well. (but is still possible with Repo Targets…just grant Read to only the appropriate targets)
In Summary, Nexus allows you to control the security of your artifacts based on the repository and/or the path of the artifact, meaning it is possible to slice and dice the system any way you see fit. My default position is to use a few Hosted Repositories as possible and control the permissions by the Repository Target.
It’s also worth mentioning that the Staging functionality in Pro also uses the Repo Targets to decide how given artifacts are staged, so the definitions are reusable across the system…and if you are using Staging you will define the
For a number of reasons you might want to require your developers to use a staging repository. Staged software releases in Nexus Professional are the best way to enable your development team to push a release to an artifact repository such as Nexus while providing management and quality assurance with a way to test and approve a release before “burning” it to production. If you want to learn how to make a staged release, you can watch this video. or read the remainder of this blog post. Continue reading
With it’s default behavior, Maven runs a plugin invocation for each project in a multi-module build. For plugins that operate on a single project at a time, this is what the author wants.
Some plugins are what we call “aggregators” which means they actually do want all the information about the full multi-module build before execution. These plugins, when run on a tree of projects cause Maven to resolve all the children before calling the plugin’s execute() method. In this mode a plugin executes just once, but effectively on the whole tree at once. (as a side note, you never want to bind an aggregator goal in your pom as this would cause the plugin to run an n! recursive build since the lifecycle would step into each child and execute the aggregator…which would cause Maven to reresolve all the children, etc)
Yesterday a minor release of the book was pushed to production. This was the first production build of the book from the Maven book’s new Github repository. We build the book from the production branch of the Git repository stored here: http://github.com/sonatype/maven-guide.
To build the book, we run the release:prepare goal and then I merge the release tag into the production branch. Once the production branch has been updated, our Hudson instance will then build and push the updated version of the book to http://www.sonatype.com/books/maven-book/reference/. We use Continuous Integration to constantly build a staging version of thes book from the master branch which is published here: http://www.sonatype.com/books/maven-book-stage/reference/.
