Configuring Maven and Other Build Tools
4.7 Apache Ant and Eclipse Aether
Eclipse Aetheris the dependency management component used in Apache Maven 3+. The project pro-vides Ant tasks that can be configured to download dependencies that can be declared in pom.xml file or in the Ant build file directly.
This configuration can be contained in your Ant build.xml or a separate file that is imported. A minimal example for resolving dependencies from a Nexus server running on localhost is shown in Minimal Setup for Aether Ant Tasks.
Minimal Setup for Aether Ant Tasks
<project xmlns:aether="antlib:org.eclipse.aether.ant" ....>
These minimal settings allow the aether:resolve task to download the declared dependencies.
To deploy build outputs to a Nexus repository with the aether:deploy task, user authentication and details about the target repositories have to be added .
Full example projects can be found in the ant-aether folder of theNexus book examples project. A full build of the simple-project, including downloading the declared dependencies and uploading the build output to Nexus can be invoked with
cd ant-aether/simple-project ant deploy
Further details about using these example projects can be found in Chapter25.
4.8 Gradle
Gradlehas a built in dependency management component that supports the Maven repository format.
In order to configure a Gradle project to resolve dependencies declared in build.gradle file, a mavenrepository as shown inMinimal Gradle Setuphas to be declared
Minimal Gradle Setup
These minimal settings allow Gradle to download the declared dependencies.
The above setup is specific to each project. Alternatively an init.gradle file placed e.g., in ~/.
gradlecan establish Nexus the source for dependencies in all projects. A simple implementation could look like
Other setup could be an expansion of the following example allowing file system based repostories:
/**
* init.gradle file for development using Nexus as proxy repository
*
* @author Manfred Moser <[email protected]
*/
apply plugin:NexusRepositoryPlugin
class NexusRepositoryPlugin implements Plugin<Gradle> {
final static String LOG_PREFIX = "init.gradle/NexusRepositoryPlugin:"
final Closure NexusConfig = { maven {
name = ’standard-nexus’
url = ’http://localhost:8081/nexus/content/groups/public’
}
// if required you can add further repositories or groups here // and they will be left intact if the name starts with standard-// although it is better to just add those repositories in Nexus // and expose them via the public group
}
final Closure RepoHandler = { all { ArtifactRepository repo ->
if (repo.name.toString().startsWith("standard-") ) {
println "$LOG_PREFIX $repo.name at $repo.url activated as ←-repository."
} else {
if (repo instanceof MavenArtifactRepository) { remove repo
println "$LOG_PREFIX $repo.name at $repo.url removed."
} else {
println "$LOG_PREFIX $repo.name kept (not a Maven repository)."
} } } }
void apply(Gradle gradle) {
// Override all project specified Maven repos with standard // defined in here
gradle.allprojects{ project ->
println "$LOG_PREFIX Reconfiguring repositories."
project.repositories RepoHandler
project.buildscript.repositories RepoHandler
project.repositories NexusConfig
project.buildscript.repositories NexusConfig }
} }
Gradle init scripts can be much more powerful and customized and are explained with more examples in theofficial Gradle documentation.
To deploy build outputs to a Nexus repository with the uploadArchives task, user authentication can be declared in e.g., gradle.properties:
nexusUrl=http://localhost:8081/nexus nexusUsername=admin
nexusPassword=admin123
and then used in the uploadArchives task with a mavenDeployer configuration from the Maven plugin:
Full example projects can be found in the gradle folder of theNexus book examples project. A full build of the simple-project, including downloading the declared dependencies and uploading the build output to Nexus can be invoked with
cd gradle/simple-project gradle upload
Further details about using these example projects can be found in Chapter25.
4.9 SBT
sbt has a built in dependency management component and defaults to the Maven repository format. In order to configure a sbt project to resolve dependencies declared in build.sbt file, a resolver as shown inMinimal SBT Configurationhas to be declared
Minimal SBT Configuration
resolvers += "Nexus" at "http://localhost:8081/nexus/content/groups/public
←-"
These minimal settings allow sbt to download the declared dependencies.
To deploy build outputs to a Nexus repository with the publish task, user credentials can be declared in the build.sbt file:
credentials += Credentials("Sonatype Nexus Repository Manager",
"nexus.scala-tools.org", "admin", "admin123")
and then used in the publishTo configuration:
publishTo <<= version { v: String =>
val nexus = "http://localhost:8081/nexus/"
if (v.trim.endsWith("SNAPSHOT"))
Some("snapshots" at nexus + "content/repositories/snapshots") else
Some("releases" at nexus + "content/repositories/releases")
Further documentation can be found in thesbt documentation on publishing.
4.10 Leiningen
Leiningenhas a built in dependency management component and defaults to the Maven repository format.
As a build tool it is mostly used for projects using theClojurelanguage. Many libraries useful for these projects are published to the Clojars repository.
If you want use Nexus with Leiningen, first create two new Maven 2 proxy repositories in Nexus with the
remote URL http://clojars.org/repo/. One of these should have the Repository Policy set to Release and the other should have policy Snapshot. Then add both to your Maven 2 public group.
In order to configure a Leinigen project to resolve dependencies declared in the project.clj file, a mirrors section overriding the built in central and clojars repositories as shown inMinimal Leiningen Configurationhas to be declared.
Minimal Leiningen Configuration
These minimal settings allow Leiningen to download the declared dependencies.
To deploy build outputs to a Nexus repository with the deploy command, the target repositories have to be add to project.clj as deploy-repositories. This avoids Leiningen checking for depen-dencies in these repositories, which is not necessary, since they are already part of the Nexus public repository group used in mirrors.
User credentials can be declared in ~/.lein/credentials.clj.gpg or will be prompted for.
Further documentation can be found on theLeiningen website.