Publishing artifacts to the local directory

We now know how to create one or more artifacts and how to use artifact configurations to group them. In this section, we will see how we can copy our artifacts to a local directory or network share. Remember that, for each artifact's configuration, Gradle adds a build<ConfigurationName> task and an upload<ConfigurationName> task. Now it is time to learn more about the upload<ConfigurationName> task so that we can copy our artifacts. In the following chapters we will also learn how to deploy to a Maven repository, an Ivy repository, and to Bintray.

For each upload<ConfigurationName> task, we must configure a repository definition. The repository definition is basically the destination of our artifacts when we upload or publish them. In this section, we use a local directory, so we define a repository using the flatDir method. We specify a name and the directory so that Gradle knows where the output of the upload<ConfigurationName> task needs to go. In Gradle projects where we have applied the Java plugin, we already have the archives artifact configuration and the uploadArchives task. We must configure the uploadArchives task and define the repository that needs to be used. In the next example build file, we will use the lib-repo local directory as the repository directory:

apply plugin: 'java'

// Define project properties.
group = 'com.mrhaki.sample'
version = '2.1'
archivesBaseName = 'sample'

// Configure the uploadArchives task.
uploadArchives {
  // Define a local directory as the
  // upload repository. The artifacts
  // must be 'published' in this
  // directory.
  repositories {
    flatDir(
      name: 'upload-repository',
      dirs: "${projectDir}/lib-repo")
  }
}

Let's see the output when we execute the uploadArchives task and check the files in the lib-repo directory:

$ gradle uploadArchives
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:jar UP-TO-DATE
:uploadArchives

BUILD SUCCESSFUL

Total time: 3.424 secs
$ ls -1 lib-repo
ivy-2.1.xml
ivy-2.1.xml.sha1
sample-2.1.jar
sample-2.1.jar.sha1
$

In our lib-repo directory, for our artifact, we have an Ivy descriptor file named ivy-2.1.xml and, for this descriptor file, a checksum file named ivy-2.1.xml.sha1. Also, we see our sample-2.1.jar artifact and the sample-2.1.jar.sha1 checksum file for our artifact. The Ivy descriptor file contains basic information about our artifact. This is shown by the following code:

<?xml version="1.0" encoding="UTF-8"?>
<ivy-module version="2.0" xmlns:m="http://ant.apache.org/ivy/maven">
  <info organisation="com.mrhaki.sample" module="java" revision="2.1" status="integration" publication="20141126060840">
    <description/>
  </info>
  <configurations>
    <conf name="archives" visibility="public" description="Configuration for archive artifacts."/>
    <conf name="compile" visibility="private" description="Compile classpath for source set 'main'."/>
    <conf name="default" visibility="public" description="Configuration for default artifacts." extends="runtime"/>
    <conf name="runtime" visibility="private" description="Runtime classpath for source set 'main'." extends="compile"/>
    <conf name="testCompile" visibility="private" description="Compile classpath for source set 'test'." extends="compile"/>
    <conf name="testRuntime" visibility="private" description="Runtime classpath for source set 'test'." extends="runtime,testCompile"/>
  </configurations>
  <publications>
    <artifact name="sample" type="jar" ext="jar" conf="archives,runtime"/>
  </publications>
</ivy-module>

We have configured the repository inside the uploadArchives task configuration. However, we can also refer to an existing repository definition that was configured in our project using the repositories configuration block. This is a good practice because we only have to define the repository once and can reuse it in multiple tasks in our build files. Let's rewrite our previous example build file, define the repository in a repositories configuration block, and refer to it from the uploadArchives task. The following code shows this:

apply plugin: 'java'

// Define project properties.
group = 'com.mrhaki.sample'
version = '2.1'
archivesBaseName = 'sample'

// Define upload repository.
repositories {
  flatDir(
    name: 'upload-repository',
    dirs: "${projectDir}/repo")
}


// Configure the uploadArchives task.
uploadArchives {
  // Refer to repository with the
  // name 'upload-repository' as the
  // repository for uploading artifacts.
  repositories.add(
    project.repositories.'upload-repository')
}

Excluding the descriptor file

By default, an Ivy descriptor file is added to the upload location. If we don't want it, we can set the uploadDescriptor property for the Upload task.

In the following example build file, we set the uploadDescriptor property to false in the uploadArchives task:

apply plugin: 'java'

// Define project properties.
group = 'com.mrhaki.sample'
version = '2.1'
archivesBaseName = 'sample'

// Define upload repository.
repositories {
  flatDir(
    name: 'upload-repository',
    dirs: "${projectDir}/lib-repo")
}

uploadArchives {
  // Exclude the descriptor file.
  uploadDescriptor = false

  repositories.add(
    project.repositories.'upload-repository')
}

When we execute the task and look at the files in the lib-repo directory, we see that the descriptor file is not added. The following code shows this:

$ gradle uploadArchives
:compileJava
:processResources
:classes
:jar
:uploadArchives

BUILD SUCCESSFUL

Total time: 1.463 secs
$ ls -1 lib-repo
sample-2.1.jar
sam
ple-2.1.jar.sha1
$
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.149.236.27