Please enable JavaScript.

Coggle requires JavaScript to display documents.

Gradle - Coggle Diagram

- - - - the dependency will be taken both at runtime and compile-time by the main code within our application
      - sub-types
        
        runtimeOnly
        
        compileOnly
      - implementation covers both subTypes
      - compiling and running production code.
      - a dependency which is assigned to the implementation configuration of a library does not end up on the compile classpath of the consumer. On the other hand, a dependency which is assigned to the api configuration of a library would end up on the compile classpath of the consumer. At runtime, however, all dependencies are required.
    - - testRuntimeOnly
      - testCompileOnly
      - used for compiling and running test code.
      - extends implementation
    - - exposes depndencies of a certain project to the client of that project, so the client does not have to add any new dependencies to his buildscript
    - - Gradle calls the scope of a dependency a configuration.
      - inheritance
        
        Under the covers the testImplementation and implementation configurations form an inheritance hierarchy by calling the method Configuration.extendsFrom(org.gradle.api.artifacts.Configuration[]).
        
        A configuration can extend other configurations to form an inheritance hierarchy. Child configurations inherit the whole set of dependencies declared for any of its superconfigurations.
      - In short, a configuration’s role is determined by the canBeResolved and canBeConsumed flag combinations:
      - Configurations are intended to be used for a single role: declaring dependencies, performing resolution, or defining consumable variants.
  - - - Dependency management is an automated technique for declaring and resolving external resources required by a project.
  - - - [versions] to declare the version numbers that plugins and libraries will reference.
      - [libraries] to define the libraries used in the build files.
      - [bundles] to define a set of dependencies.
      - [plugins] to define plugins.
  - - - A component metadata rule is a rule that modifies a component’s metadata after it was fetched from a repository, e.g. to add missing information or to correct wrong information.
      - In contrast to resolution rules, component metadata rules are applied before resolution starts. Component metadata rules are defined as part of the build logic and can be shared through plugins.
    - - Each component consists of one or more variants. A variant consists of a set of artifacts and defines a set of dependencies. It is identified by a set of attributes and capabilities.
      - Gradle’s dependency resolution is variant-aware and selects one or more variants of each component after a component (i.e. one version of a module) has been selected. It may also fail if the variant selection result is ambiguous, meaning that Gradle does not have enough information to select one of multiple mutual exclusive variants. In that case, more information can be provided through variant attributes. Examples of variants each Java components typically offers are api and runtime variants.
      - Variant Attribute
        
        Attributes are used to identify and select variants. A variant has one or more attributes defined, for example org.gradle.usage=java-api, org.gradle.jvm.version=11.
        
        When dependencies are resolved, a set of attributes are requested and Gradle finds the best fitting variant(s) for each component in the dependency graph. Compatibility and disambiguation rules can be implemented for an attribute to express compatibility between values (e.g. Java 8 is compatible with Java 11, but Java 11 should be preferred if the requested version is 11 or higher). Such rules are typically provided by plugins.
  - - - Releases of a module provide metadata. Metadata is the data that describes the module in more detail e.g. information about the location of artifacts or required transitive dependencies.
      - Gradle offers its own metadata format called Gradle Module Metadata (.module file) but also supports Maven (.pom) and Ivy (ivy.xml) metadata.
      - Metadata describes dependencies. Some examples of metadata include:
        
        coordinates for finding the dependency in a repository
        
        information about the project that created the dependency
        
        the authors of the dependency
        
        other dependencies required for a dependency to work properly, known as transitive dependencies
    - - represents a distinct set of changes of a released module.
      - For example 18.0 represents the version of the module with the coordinates com.google:guava:18.0. In practice there’s no limitation to the scheme of the module version. Timestamps, numbers, special suffixes like -GA are all allowed identifiers.
      - The most widely-used versioning strategy is semantic versioning.
  - - - module set: often a set of modules published together as a whole. Using one module of the set often means we want to use the same version for all modules of the set. For example, if using groovy 1.2, also use groovy-json 1.2.
      - runtime environment: a set of libraries known to work well together. e.g., the Spring Platform, recommending versions for both Spring and components that work well with Spring.
      - deployment environment: Java runtime, application server, …
  - - - In case of a version conflict, Maven will take the shortest path to a dependency and use that version. In case there are multiple paths of the same length, the first one wins.
    - - Version conflicts
        
        That is when two or more dependencies require a given dependency but with different versions.
        
        Gradle will consider all requested versions, wherever they appear in the dependency graph. Out of these versions, it will select the highest one.
      - Implementation conflicts
        
        That is when the dependency graph contains multiple modules that provide the same implementation, or capability in Gradle terminology.
    - - optimistic upgrade
        
        When you declare a version using the short-hand notation, for example
        implementation("org.slf4j:slf4j-api:1.7.15")
        Then the version is considered a required version which means that it should minimally be 1.7.15 but can be upgraded by the engine
      - strict versions
        
        using the !! notation: implementation("org.slf4j:slf4j-api:1.7.15!!")
        
        A strict version cannot be upgraded and overrides whatever transitive dependencies originating from this dependency provide.
        
        It is recommended to use ranges for strict versions.
        
        The notation [1.7, 1.8[!!1.7.25 is equivalent to: strictly [1.7, 1.8[ but prefer prefer 1.7.25 which means that the engine must select a version between 1.7 (included) and 1.8 (excluded), and that if no other component in the graph needs a different version, it should prefer 1.7.25.
      - Declaring a dependency without version
        
        A recommended practice for larger projects is to declare dependencies without versions and use dependency constraints for version declaration. The advantage is that dependency constraints allow you to manage versions of all dependencies, including transitive ones, in one place.
      - rich versions
        
        strictly
        
        Any version not matched by this version notation will be excluded. This is the strongest version declaration. On a declared dependency, a strictly can downgrade a version. When on a transitive dependency, it will cause dependency resolution to fail if no version acceptable by this clause can be selected.
        
        This term supports dynamic versions. When defined, this overrides any previous require declaration and clears previous reject.
        
        require
        
        Implies that the selected version cannot be lower than what require accepts but could be higher through conflict resolution, even if higher has an exclusive higher bound. This is what a direct dependency translates to. This term supports dynamic versions.
        
        When defined, this overrides any previous strictly declaration and clears previous reject.
        
        prefer
        
        This is a very soft version declaration. It applies only if there is no stronger non dynamic opinion on a version for the module. This term does not support dynamic versions.
        
        Definition can complement strictly or require.
        
        reject
        
        Declares that specific version(s) are not accepted for the module. This will cause dependency resolution to fail if the only versions selectable are also rejected. This term supports dynamic versions.
      - dynamic versions
        
        A dynamic version can be either a version range (e.g. 2.+) or it can be a placeholder for the latest version available e.g. latest.integration.
        
        changing version
        
        . An example of this type of changing module is a Maven SNAPSHOT module, which always points at the latest artifact published. In other words, a standard Maven snapshot is a module that is continually evolving, it is a "changing module".
        
        A changing version indicates that the feature set is still under active development and hasn’t released a stable version for general availability yet.
        
        By default, Gradle caches dynamic versions of dependencies for 24 hours. Within this time frame, Gradle does not try to resolve newer versions from the declared repositories. The threshold can be configured as needed for example if you want to resolve new versions earlier.
      - dependency locking
        
        To achieve reproducible builds, it is necessary to lock versions of dependencies and transitive dependencies such that a build with the same inputs will always resolve the same module versions.
- - - - Declare local variables with the val keyword. Local variables are only visible in the scope where they have been declared. They are a feature of the underlying Kotlin language.
    - - Gradle’s enhanced objects, including projects, tasks, and source sets, can hold user-defined properties.
      - Add, read, and set extra properties via the owning object’s extra property. Alternatively, you can access extra properties via Kotlin delegated properties using by extra.
- - - - Binary plugins are written either programmatically by implementing the Plugin interface or through declarations in either Groovy or Kotlin DSL. They can reside within a build script, the project hierarchy, or externally in a plugin jar.
      - A Gradle plugin resolved as a dependency rather than compiled from source is a binary plugin.
    - - Script plugins are additional build scripts that further configure the build and usually implement a declarative approach to manipulating the build. They are typically used within a build but can be externalized and accessed remotely.
  - - - The Java plugin adds Java compilation along with testing and bundling capabilities to a project.
      - tasks
        
        source code tasks
        
        compileJava
        
        Compiles production Java source files using the JDK compiler.
        
        Depends on: All tasks which contribute to the compilation classpath, including jar tasks from projects that are on the classpath via project dependencies
        
        processResources
        
        Copies production resources into the production resources directory.
        
        classes
        
        Depends on: compileJava, processResources
        
        This is an aggregate task that just depends on other tasks. Other plugins may attach additional compilation tasks to it.
        
        jar
        
        Depends on: classes
        
        Assembles the production JAR file, based on the classes and resources attached to the main source set.
        
        javadoc
        
        Depends on: classes
        
        Generates API documentation for the production Java source using Javadoc.
        
        test tasks
        
        compileTestJava
        
        Compiles test Java source files using the JDK compiler.
        
        Depends on: classes, and all tasks that contribute to the test compilation classpath
        
        processTestResources
        
        Copies test resources into the test resources directory.
        
        testClasses
        
        Depends on: compileTestJava, processTestResources
        
        This is an aggregate task that just depends on other tasks. Other plugins may attach additional test compilation tasks to it.
        
        test
        
        Depends on: testClasses, and all tasks which produce the test runtime classpath
        
        Runs the unit tests using JUnit or TestNG.
    - - defines tasks that package and distribute an application, such as the run task.
    - - The Base Plugin provides some tasks and conventions that are common to most builds and adds a structure to the build that promotes consistency in how they are run. Its most significant contribution is a set of lifecycle tasks that act as an umbrella for the more specific tasks provided by other plugins and build authors.
      - tasks
        
        clean
        
        Deletes the build directory and everything in it, i.e. the path specified by the layout.buildDirectory project property.
        
        check
        
        Plugins and build authors should attach their verification tasks, such as ones that run tests, to this lifecycle task using check.dependsOn(task)
        
        assemble
        
        Plugins and build authors should attach tasks that produce distributions and other consumable artifacts to this lifecycle task. For example, jar produces the consumable artifact for Java libraries. Attach tasks to this lifecycle task using assemble.dependsOn(task).
        
        build
        
        Depends on: check, assemble
        
        Intended to build everything, including running all tests, producing the production artifacts and generating documentation. You will probably rarely attach concrete tasks directly to build as assemble and check are typically more appropriate.
        
        buildConfiguration (task rule)
        
        Assembles those artifacts attached to the named configuration. For example, buildRuntimeElements will execute any task that is required to create any artifact attached to the runtimeElements configuration.
        
        cleanTask
        
        Removes the defined outputs of a task, e.g. cleanJar will delete the JAR file produced by the jar task of the Java Plugin.
  - - - Extend the basic Gradle model (e.g. add new DSL elements that can be configured).
      - Apply specific configuration (e.g. add organizational repositories or enforce standards).
      - Add new properties and methods to existing types via extensions.
  - - - The plugins{} block can only be used in a project’s build script build.gradle(.kts) and the settings.gradle(.kts) file. It must appear before any other block. It cannot be used in script plugins or init scripts.
- - - - runs the task
    - - list alle tasks available for a certain build.gradle file
    - - build with additional logs
    - - gradle [...] --console=plain
    - - gradle [...] --build-cache
        gradle [...] --no-build-cache
    - - gradle [taskName1 taskName2...] [--option-name...]
    - - to initialize a gradle repo
    - - You can see the project paths
- - - - mustRunAfter
        
        it applies to an order of execution of a task with this clause specified
      - shouldRunAfter
        
        basically the same as mustRunAfter but ignores circular dependencies
      - finalizedBy
        
        kind of opposite of mustRunAfter, because it invokes task defined in closure of invoked task
  - - - Built-in task - Gradle provides built-in utility tasks such as Copy, Jar, Zip, Delete, etc…
      - Custom task - Gradle allows users to subclass DefaultTask to create their own task types.
- - - - Multi-Project Builds using buildSrc
        
        The buildSrc directory is automatically recognized by Gradle. It is a good place to define and maintain shared configuration or imperative build logic, such as custom tasks or plugins.
        buildSrc is automatically included in your build as a special subproject if a build.gradle(.kts) file is found under buildSrc.
      - Composite Builds
        
        Composite Builds, also referred to as included builds, are best for sharing logic between builds (not subprojects) or isolating access to shared build logic (i.e., convention plugins).
  - - - The primary purpose of the settings file is to add subprojects to your build.
      - The settings file is typically found in the root directory of the project.
      - contains rootProject.name property and include()
      - Gradle reads the settings.gradle.kts file to figure out which subprojects comprise a project build.
      - can hold information that the build file might need e.g. versions numbers
      - The settings file is composed of Gradle API calls built on top of the DSLs. Gradle executes the script line by line, top to bottom.
      - Plugins applied to the settings only affect the Settings object.
      - It’s important to remember that while many Gradle scripts are typically written in short Groovy or Kotlin syntax, every item in the settings script is essentially invoking a method on the Settings object in the Gradle API. include("app") is actually settings.include("app")
      - The pluginManagement{} block may only appear in the settings.gradle(.kts) file, where it must be the first block in the file or in an Initialization Script
    - - To permanently enable verbose mode, add org.gradle.console=verbose to your gradle.properties file.
      - Enable caching every time you run the build org.gradle.caching=true
  - - - It can be set with the environment variable GRADLE_USER_HOME.
      - By default, the Gradle User Home (~/.gradle or C:\Users\<USERNAME>.gradle) stores global configuration properties, initialization scripts, caches, and log files.
- - - - libs
        
        a folder with a jar file named after the name of the project
      - classes
        
        compiled java classes
      - tmp
      - generated
  - - - gradle determines which projects will be part of this particular build
    - - executing the build scripts of all the projects
    - - works out which tasks will be executed and this is determined by task name that passes the argument on the gradle command line
- - - - local
        
        When both remote and local caches are enabled, then the build output is first checked in the local cache. If the output isn’t present in the local cache, it’ll be downloaded from the remote cache and also stored in the local cache.
      - remote
- - - - --dependency <dependency> (mandatory)
        
        The dependency to investigate. You can supply a complete group:name, or part of it. If multiple dependencies match, Gradle generates a report covering all matching dependencies.
      - --configuration <name> (mandatory)
        
        The dependency configuration which resolves the given dependency. This parameter is optional for projects that use the Java plugin, since the plugin provides a default value of compileClasspath.
      - --single-path (optional)
        
        Render only a single path to the dependency.