Gradle User Guide (Chapter 8: Fundamentals of Dependency Management)

Chapter 8: Fundamentals of Dependency Management

This chapter will cover some of the basics of gradle dependency Management

1. What is dependency management?

   In short, dependency management is made up of two parts. First, Gradle need to know what projects you want to build or run in order to find them. We treat these imported files as dependencies of the project. Second, Gradle needs to build or package your project products. We treat these exported files as publications of the project. Below, let's learn more about these two aspects in detail.

   Most of the projects are not completely independent. They require build files for other projects for compilation, testing, and so on. For example, in order to use Hibernate in my project, I need to add some hibernate jar packages to classpath when compiling my source files. In order to run the test, I need to add some additional jar packages under test classpath, such as the unique JDBC driver, the Java caching framework.

   These projects rely on files that need to be imported. Gradle allows you to tell it which files your project depends on, so it cares about what dependencies to look for and effectively imports them into your project. These dependencies may be downloaded from a remote maven or ivy, in a local repository, or in another project in a multi-project build. We call this process dependency resolution.

   Note that this feature is the advantage of gradle relative to Ant. In ant, you can only load jar packages that specify absolute or relative paths. With Gradle, you simply declare these "names" and hierarchies in your dependencies to determine where to obtain them. You can add Apache Ivy to get a similar operation of Ant, the single gradle can do better.

   The project's dependent files themselves often have their own dependencies. For example, running the Hibernate core library requires declaring several other class libraries in classpath. So, when Gradle tests your project, you also need to find and load these dependent files. We can call it dependency transfer.

   The main goal of most projects is to build some files that can be run outside the project. For example, if your project product is a Java library, you need to build a jar package, or a jar source file and some documents, and publish them in some places.

   Gradle is also responsible for the important work of releasing project documents. You declare the project's release package, Gradle is responsible for building and publishing them. Exactly, these release packages depend on the work you want to do. You may want to copy these files to a local directory, or upload them to a remote Maven or Ivy warehouse, or use them in other projects in multiple projects. We generally call this process for release.

3. Declare your dependence.

   Let's take a look at some of the dependency declarations. The following is a basic build script:

   What's going on here? This build script describes a little content for this project. First, it requires hibernate core 3.6.7.Final to compile the project source file, which means that the dependency of hibernate core is required in the run. The script also specifies that the test project requires any JUnit >= 4.0 repository. It also showed Gradle the need to visit the MAVEN central repository to find dependent files. We'll have a more detailed description of the next fragment.

4. Dependent Configuration Items

   Gradle dependencies are grouped according to configuration items, and a configuration item contains a simple set of named dependencies. We will refer to these configuration items. You can use them to declare external dependencies for your project. As we will see later, they are also used to declare your project product.

   The Java plug-in defines a number of standard configuration items. The classpath used by these configuration code Java plugins. Below we list some common items, and of course you can see more details in Table 23.5, "Java plugin-dependency Configurations" .

   Compile

   Dependencies required when compiling project source code

   Runtime

   The dependencies required to run the project classes. By default, it also contains compile-time dependencies.

   Testcompile

   The dependencies that are required to compile the project test source code. By default, it also contains compiled source files and compile-time dependencies.

   Testruntime

   The dependencies required to run the test. By default, it also contains compilation, run, and test compile-time dependencies.

   Different plug-ins provide different, more in-depth standard configuration items. You can also define your own unique configuration items in your build script. Please view the definition configuration item details in section 51.3, "Dependency configurations".

6. external dependencies

   defines an external dependency and adds it to the configuration item:

   seek more dependency definitions and work:  section  51.4, "How to declare your dependencies".

8. warehouse

   gradle find external dependent files? Gradle first looked from the warehouse, and a warehouse was assembled with many files grouped, named, and versioned. Gradle can identify different types of warehouses such as Maven, Ivy, and can access these warehouses in different ways, such as local file systems, HTTP, and so on.

   Span style= "FONT-SIZE:14PT;" > or a remote Ivy Warehouse:

   Finally, you can also set up the warehouse in the local file system. This approach is effective for Maven and Ivy.

   to find out more about defining and working with repositories, which has a look at  section 51.6, "repositories".

10. Publish Project Artifacts

    Dependent configuration items can also be used in the publish file. We often call it a release artifact or just a workpiece. Plug-ins support the project release artifacts very well, and usually you don't have to declare to gradle what you need to publish. In any case, you still need to state where these artifacts are published. You can do this by attaching a warehouse to the Uploadarchives task. The following is an example of publishing to a remote Ivy warehouse:

    Now, when you execute Gradle uploadarchives,gradle, you build and upload your jar package. Gradle will also generate and upload a ivy.xml at the same time.

    Of course, you can also post to the MAVEN central repository. These grammars are slightly different. Note that the Maven plugin needs to be added to the MAVEN repository. When the configuration is complete, Gradle generates and uploads a pom.xml.

    To find out more about publication, with a look at Chapter, Publishing artifacts.

12. What is the next chapter?

    If you are interested in DSLs, you can go to Chapter 9 for details.

Gradle User Guide (Chapter 8: Fundamentals of Dependency Management)