In the previous chapters, we learned how to define and use dependencies in our projects. However, the code we write in our projects can also be a dependency for another project. In order for another project to use our code as a dependency, we should publish our code as a dependency artifact so that it can be used by other projects.
In this chapter, you will learn how you can define artifacts in your project. These artifacts need to be published for others to use them. We first publish them using a filesystem, so the artifacts can be used from the same computer or even if we use a network share on an intranet. In later chapters, we will see how to publish our artifacts to a Maven repository, an Ivy repository, and Bintray.
A Gradle project can contain artifacts we want to publish. An artifact can be a ZIP or JAR archive file or any other file. We can define one or more artifacts in one project. Thus, we don't have to create two different projects if we want to have two different artifacts from the same source tree.
In Gradle, we group artifacts using configurations. We used configurations to define dependencies for our project, but now we will use the configurations to group our artifacts that can be dependencies for others. So a configuration can contain both dependencies and artifacts. If we apply the Java plugin to our project, we get a configuration named archives, that contains the default JAR artifact for the project.
In the following example Gradle build file, we use the Java plugin. We add a task to display the filename of the artifact that belongs to the archives configuration. The following code shows this:
apply plugin: 'java'
// Set the archivesBaseName property,
// to change the name of the
// default project artifact.
archivesBaseName = 'java_lib'
task artifactsInfo << {
// Find archives configuration
// and display file name(s)
// for artifacts belonging
// to the configuration.
configurations
.findByName('archives')
.allArtifacts
.each { artifact ->
println artifact.file.name
}
}When we run the artifactsInfo task from the command line, we see the java_lib.jar filename in the output. The following code shows this:
$ gradle artifactsInfo :artifactsInfo java_lib.jar BUILD SUCCESSFUL Total time: 1.088 secs
For each configuration in our project, Gradle adds two tasks to the project: build<ConfigurationName> and upload<ConfigurationName>. The build<ConfigurationName> task creates the artifacts for the given configuration name. The upload<ConfigurationName> task creates and uploads the artifacts for the given configuration name. The upload<ConfigurationName> task needs extra configuration to know where to upload the artifacts. We will see later in this chapter how to configure the task.
In our example project, we have the buildArchives and uploadArchives tasks. Let's run the buildArchives task for our example project and see which tasks are executed:
$ gradle buildArchives :compileJava :processResources :classes :jar :buildArchives BUILD SUCCESSFUL Total time: 1.209 secs $ ls build/libs java_lib.jar
Here, we can see that first everything is prepared in our Java project to create the JAR artifact. The JAR artifact is then added to the artifacts configuration. The java_lib.jar JAR file that is created can be found in the build/libs directory.
If we set the version property for our project, then it will be used in the name of our created artifact. In the next example build file, we will set the version property and look at the name that is created for the artifact:
apply plugin: 'java'
archivesBaseName = 'java_lib'
// Set project version,
// which is then used in the
// artifact name.
version = '2.3'
task artifactsInfo << {
configurations
.findByName('archives')
.allArtifacts
.each { artifact ->
println artifact.file.name
}
}Let's run the artifactsInfo task to see the name of our artifact:
$ gradle artifactsInfo :artifactsInfo java_lib-2.3.jar BUILD SUCCESSFUL Total time: 2.831 secs