Gradle build script describes a process of building projects. Most of the projects are not self-contained. They need some files to compile and test the source files. For example, to use Hibernate, we must include some Hibernate JARs in the classpath. Gradle uses some unique script to manage the dependencies, which needs to be downloaded.
The dependencies are used to assist a task, such as required JAR files of the project and external JARs. Every dependency is applied to a specified scope. For example, dependencies are used to compile the source code, and some will be available at runtime. Gradle signifies the scope of a dependency with the help of a Configuration, and a unique name can recognize every configuration.
Most of the Gradle plugins support pre-defined configuration for the projects.
Gradle considers the outcomes of building and publishing the projects. Publishing is based on the task that we define. It can copy the files to a local directory or upload them to a remote Maven or lvy repository. We can use these files from another project in the same multi-project build. The process of publishing a task is called publication.
Dependency configurations
Dependency configuration is a set of dependencies and artifacts. Following are three main tasks of configuration:
- Declaring dependencies
- Resolving dependencies
- Exposing artifacts for consumptions
Declaring Dependency
Dependency is an essential part of any project. We must declare a dependency to use it. Dependency configuration is a process of defining a set of dependencies. This feature is used to declare external dependencies, which we want to download from the web.
Consider the below example of the Hibernate-core dependency:
A dependency can be used on different phases of the project. These phases can be:
Compile: At compile time, we will use the dependencies that are required to compile the production source of the project.
Runtime: These dependencies are used at runtime by production classes. By default, it also contains the compile-time dependencies.
Test Compile: These dependencies are required to compile the test source of the project. It also contains the compiled production classes and the compile-time dependencies.
Test Runtime: These dependencies are required to run the tests. It also contains runtime and test compile dependencies.
Resolving Dependencies
The plugin uses the configuration and gets input for the tasks defined. For example, the Gradle project uses the Spring Web Framework jar file, which must be downloaded from Maven Central.
Exposing Artifacts for Consumption
The plugin uses configurations that are used to define artifacts for other projects consumption.
Dependency Management
A software project is a collection of various functionality. It rarely works in isolation. In most cases, a project depends on the reusability of libraries. Also, a project can be divided into separate components to form a modularized system. Dependency management is a process for declaring, resolving, and using dependencies required by the project in an automated fashion. The figure below demonstrates the structure of a Gradle project.
Gradle provides built-in support for dependency management. In Gradle, dependency management is made up of two things. They are as follows:
- Gradle must know the requirements of the project to build or to run a project. These files are said as the dependencies of the project.
- Gradle needs to build and upload data that is produced by a project. These files are the declaration of the project.
In Gradle, mostly projects are not independent. Projects need files that were built by other projects for compilation or to test and more. For example, if we want to use the Hibernate framework in a project, we would need the hibernate jar file in the classpath at compile time. These files are said as the dependency of the project. In Gradle, we can specify the dependencies of a project, and Gradle focuses on finding these dependencies and make it available in the project. We can download these dependencies from remote Maven or Ivy repository, or we can build our dependency in a project and include it. This process is known as dependency resolution.
Dependency resolution provides an advantage over Ant. Using Ant, we can specify absolute or relative paths of jars to load. Comparatively, in Gradle, we have to declare the name of the dependencies to define the dependency. Also, Ant reflects the similar behavior when we add Apache Ivy, so Gradle is better in this case.
The dependency of a project itself behaves as a dependency; for example, in hibernate-core, we require many libraries that must be available on the classpath. So when the Gradle test runs a project, it searches the dependencies and makes it available. These dependencies are known as transitive dependencies.
No comments:
Post a Comment