• No results found

Apache Ant and Eclipse Aether

In document Repository Management with Nexus (Page 64-71)

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 mini-mal example for resolving dependencies from a repository manager 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 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 thedocumentation 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 the repository as the the source for dependencies in all projects. A simple imple-mentation could look like

Other setup could be an expansion of the following example allowing file system based repostories:

/**

* init.gradle file for development using the Nexus Repository Manager as ←-proxy repository

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

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 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 thedocumentation examples project. A full build of the simple-project, including downloading the declared dependencies and uploading the build output to repository manager 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")

Tip

The credentials string should never change, as third-party clients depend on it

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.

Chapter 5

In document Repository Management with Nexus (Page 64-71)