
When you search for artifacts using http://repository.sonatype.org, the browser is querying the Nexus repository using a REST API. In this post, I’m going to show you some simple Ruby scripts which you can use to search the Maven repository ...
If you are looking for the easiest way to search for artifacts in the Central Maven Repository, go to http://repository.sonatype.org. Sonatype maintains a publi instance of Nexus that can be used to search for artifacts by GAV (groupId, artifactId...
A common question from Apache Maven users is “How do I search the central repository?” or “How do I find out what groupId or artifactId I should use for a specific dependency?” Use Sonatype’s Nexus installation at htt...
One of the users on the m2eclipse user list has some great feedback about a presentation he did at the Stockholm JUG on the best of breed Maven tooling which includes Nexus and m2eclipse. Apparently people are impressed with the Maven support insi...
Maven 3.0 uses a new standalone component that handles inheritance and interpolation of a model in any format. The model needn’t even be XML based. If you can translate your model into a list of property-value pairs, you can use this framewo...
There’s are lots of people who already know that Mark de Visser is the new CEO of Sonatype, but Zack wrote a nice bit about it today in his InfoWorld blog: http://weblog.infoworld.com/openresource/archives/2008/11/marketing_maven.html I am r...
The settings element in the settings.xml file
contains elements used to define values which configure Maven execution.
Settings in this file are settings which apply to many projects and which
should not be bundled to any specific project, or distributed to an
audience. These include values such as the local repository location,
alternate remote repository servers, and authentication information. There
are two locations where a settings.xml file may
live:
Maven Installation Directory:
$M2_HOME/conf/settings.xml
User-specific Settings File:
~/.m2/settings.xml
Here is an overview of the top elements under settings:
Example A.1. Overview of top-level elements in settings.xml
<settings xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"> <localRepository/> <interactiveMode/> <usePluginRegistry/> <offline/> <pluginGroups/> <servers/> <mirrors/> <proxies/> <profiles/> <activeProfiles/> </settings>
Half of the top-level settings elements are simple values, representing a range of values which configure the core behavior of Maven:
Example A.2. Simple top-level elements in settings.xml
<settings xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"> <localRepository>${user.dir}/.m2/repository</localRepository> <interactiveMode>true</interactiveMode> <usePluginRegistry>false</usePluginRegistry> <offline>false</offline> <pluginGroups> <pluginGroup>org.codehaus.mojo</pluginGroup> </pluginGroups> ... </settings>
The simple top-level elements are:
This value is the path of this build system's local
repository. The default value is
${user.dir}/.m2/repository.
true if Maven should attempt to interact
with the user for input, false if not. Defaults
to true.
true if Maven should use the
${user.dir}/.m2/plugin-registry.xml file to
manage plugin versions, defaults to
false.
true if this build system should operate
in offline mode, defaults to false. This
element is useful for build servers which cannot connect to a
remote repository, either because of network setup or security
reasons
This element contains a list of
pluginGroup elements, each contains a
groupId. The list is searched when a plugin is
used and the groupId is not provided in the
command line. This list contains
org.apache.maven.plugins by default.
The distributionManagement element of the
POM defines the repositories for deployment. However,
certain settings such as security credentials should not be distributed
along with the pom.xml. This type of information
should exist on the build server in the
settings.xml.
Example A.3. Server configuration in settings.xml
<settings xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"> ... <servers> <server> <id>server001</id> <username>my_login</username> <password>my_password</password> <privateKey>${usr.home}/.ssh/id_dsa</privateKey> <passphrase>some_passphrase</passphrase> <filePermissions>664</filePermissions> <directoryPermissions>775</directoryPermissions> <configuration></configuration> </server> </servers> ... </settings>
The elements under server are:
This is the id of the server (not of the
user to login as) that matches the
distributionManagement repository element's
id.
These elements appear as a pair denoting the login and password required to authenticate to this server.
Like the previous two elements, this pair specifies a path
to a private key (default is
${user.home}/.ssh/id_dsa) and a passphrase,
if required. The passphrase and password elements may be
externalized in the future, but for now they must be set
plain-text in the settings.xml file.
When a repository file or directory is created on deployment, these are the permissions to use. The legal values of each is a three digit number corresponding to *nix file permissions, i.e. 664, or 775.
Example A.4. Mirror configuration in settings.xml
<settings xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"> ... <mirrors> <mirror> <id>planetmirror.com</id> <name>PlanetMirror Australia</name> <url>http://downloads.planetmirror.com/pub/maven2</url> <mirrorOf>central</mirrorOf> </mirror> </mirrors> ... </settings>
The unique identifier of this mirror. The id is used to differentiate between mirror elements.
The base URL of this mirror. The build system will use prepend this URL to connect to a repository rather than the default server URL.
The id of the server that this is a mirror of. For example, to point to a mirror of the Maven central server (http://repo1.maven.org/maven2), set this element to central. This must not match the mirror id.
Example A.5. Proxy configuration in settings.xml
<settings xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"> ... <proxies> <proxy> <id>myproxy</id> <active>true</active> <protocol>http</protocol> <host>proxy.somewhere.com</host> <port>8080</port> <username>proxyuser</username> <password>somepassword</password> <nonProxyHosts>*.google.com|ibiblio.org</nonProxyHosts> </proxy> </proxies> ... </settings>
The unique identifier for this proxy. This is used to differentiate between proxy elements.
true if this proxy is active. This is
useful for declaring a set of proxies, but only one may be
active at a time.
The protocol://host:port of the proxy,
separated into discrete elements.
These elements appear as a pair denoting the login and password required to authenticate to this proxy server.
This is a list of hosts which should not be proxied. The delimiter of the list is the expected type of the proxy server; the example above is pipe delimited - comma delimited is also common.
The profile element in the
settings.xml is a truncated version of the
pom.xml profile element. It consists of the
activation, repositories,
pluginRepositories and properties
elements. The profile elements only include these four elements because
they concern themselves with the build system as a whole (which is the
role of the settings.xml file), not about
individual project object model settings.
If a profile is active from settings, its values will override any
equivalent profiles which matching identifiers in a
POM or profiles.xml file.
Activations are the key of a profile. Like the POM's profiles, the power of a profile comes from its ability to modify some values only under certain circumstances; those circumstances are specified via an activation element.
Example A.6. Defining Activation Parameters in settings.xml
<settings xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"> ... <profiles> <profile> <id>test</id> <activation> <activeByDefault>false</activeByDefault> <jdk>1.5</jdk> <os> <name>Windows XP</name> <family>Windows</family> <arch>x86</arch> <version>5.1.2600</version> </os> <property> <name>mavenVersion</name> <value>2.0.3</value> </property> <file> <exists>${basedir}/file2.properties</exists> <missing>${basedir}/file1.properties</missing> </file> </activation> ... </profile> </profiles> ... </settings>
Activation occurs when all specified criteria have been met, though not all are required at once.
activation has a built in, Java-centric check in the jdk element. This will activate if the test is run under a jdk version number that matches the prefix given. In the above example, 1.5.0_06 will match.
The os element can define some operating
system specific properties shown above.
The profile will activate if Maven detects a property (a value which can be dereferenced within the POM by ${name}) of the corresponding name=value pair.
Finally, a given filename may activate the profile by the existence of a file, or if it is missing.
The activation element is not the only way that
a profile may be activated. The settings.xml file's
activeProfile element may contain the profile's id.
They may also be activated explicitly through the command line via a
comma separated list after the P flag (e.g. -P
test).
To see which profile will activate in a certain build, use the maven-help-plugin.
mvn help:active-profiles
Maven properties are value placeholder, like properties in Ant.
Their values are accessible anywhere within a POM by
using the notation ${X}, where X is the property.
They come in five different styles, all accessible from the settings.xml
file:
env.XPrefixing a variable with env. will
return the shell’s environment variable. For
example, ${env.PATH} contains the
$path environment variable.
(%PATH% in Windows.)
project.xA dot-notated (.) path in the POM will contain the corresponding elements value.
settings.xA dot-notated (.) path in the settings.xml will contain the
corresponding elements value.
All properties accessible via
java.lang.System.getProperties() are
available as POM properties, such as
${java.home}.
xSet within a properties element or an
external file, the value may be used as ${someVar}.
Example A.7. Setting the ${user.install} property in settings.xml
<settings xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"> ... <profiles> <profile> ... <properties> <user.install>${user.dir}/our-project</user.install> </properties> ... </profile> </profiles> ... </settings>
The property ${user.install} is accessible from
a POM if this profile is active.
Repositories are remote collections of projects from which Maven uses to populate the local repository of the build system. It is from this local repository that Maven calls it plugins and dependencies. Different remote repositories may contain different projects, and under the active profile they may be searched for a matching release or snapshot artifact.
Example A.8. Repository Configuration in settings.xml
<settings xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"> ... <profiles> <profile> ... <repositories> <repository> <id>codehausSnapshots</id> <name>Codehaus Snapshots</name> <releases> <enabled>false</enabled> <updatePolicy>always</updatePolicy> <checksumPolicy>warn</checksumPolicy> </releases> <snapshots> <enabled>true</enabled> <updatePolicy>never</updatePolicy> <checksumPolicy>fail</checksumPolicy> </snapshots> <url>http://snapshots.maven.codehaus.org/maven2</url> <layout>default</layout> </repository> </repositories> <pluginRepositories> ... </pluginRepositories> ... </profile> </profiles> ... </settings>
These are the policies for each type of artifact, Release or snapshot. With these two sets, a POM has the power to alter the policies for each type independent of the other within a single repository. For example, one may decide to enable only snapshot downloads, possibly for development purposes.
true or false for
whether this repository is enabled for the respective type
(releases or snapshots).
This element specifies how often updates should attempt to
occur. Maven will compare the local POMs
timestamp to the remote. The choices are:
always, daily (default),
interval:X (where X is an integer in minutes)
or never.
When Maven deploys files to the repository, it also
deploys corresponding checksum files. Your options are to
ignore, fail, or
warn on missing or incorrect
checksums.
In the above description of repositories, it was mentioned
that they all follow a common layout. This is mostly correct.
Maven 2 has a default layout for its repositories; however,
Maven 1.x had a different layout. Use this element to specify
which if it is default or legacy. If you are upgrading from
Maven 1 to Maven 2, and you want to use the same repository
which was used in your Maven 1 build, list the layout as
legacy.
The structure of the pluginRepositories element
block is similar to the repositories element. The
pluginRepository elements each specify a remote
location of where Maven can find plugins artifacts.
Example A.9. Plugin Repositories in settings.xml
<settings xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
...
<profiles>
<profile>
...
<repositories>
...
</repositories>
<pluginRepositories>
<pluginRepository>
<id>codehausSnapshots</id>
<name>Codehaus Snapshots</name>
<releases>
<enabled>false</enabled>
<updatePolicy>always</updatePolicy>
<checksumPolicy>warn</checksumPolicy>
</releases>
<snapshots>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
<checksumPolicy>fail</checksumPolicy>
</snapshots>
<url>http://snapshots.maven.codehaus.org/maven2</url>
<layout>default</layout>
</pluginRepository>
</pluginRepositories>
...
</profile>
</profiles>
...
</settings>
Example A.10. Setting active profiles in settings.xml
<settings xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"> ... <activeProfiles> <activeProfile>env-test</activeProfile> </activeProfiles> </settings>
The final piece of the settings.xml puzzle is
the activeProfiles element. This contains a set of
activeProfile elements, which each have a value of a
profile id. Any profile id defined as an
activeProfile will be active, regardless of any
environment settings. If no matching profile is found nothing will
happen. For example, if env-test is an
activeProfile, a profile in a
pom.xml (or profile.xml with a
corresponding id it will be active. If no such profile is found then
execution will continue as normal.

