<commit_before>---
layout: article
title: Introducción a Gradle
categories: [gradle, build, integración, scm]
featured: true
---

![Gradle logo](/img/wiki/gradle_logo2.png)

# Introducción

Gradle es una herramienta que ayuda a desarrollar un proyecto basado en el entorno de una JDK (Java, Kotlin, Xtend, Scala, Groovy, etc.) y que cumple con las siguientes funciones principales que vamos a explicar en las siguientes secciones:

- Reificación del Proyecto
- Manejo de Dependencias a partir de repositorios locales y remotos
- Plugins y tareas

# Reificación de Proyecto

Java no trabaja la idea de proyecto, no lo representa como concepto, y esto se traslada a todos los lenguajes basados en la JDK. Entonces, cada uno de los IDEs pensados para Java agregan su propia forma de definirlo: 

- en Eclipse tenemos los archivos `.classpath` y `.project`
- en IntelliJ tenemos el directorio oculto `.idea`
- en Visual Studio Code tenemos el directorio `.vscode`

Gradle permite trabajar en cualquiera de estos IDEs con su propio modelo de proyecto, que se guarda en el archivo `build.gradle.kts` en el caso de trabajar utilizando el lenguaje Kotlin o `build.gradle` a secas, cuando la configuración se hace utilizando el lenguaje Groovy. A partir de ahora vamos a continuar la explicación asumiendo que estás usando Gradle con Kotlin.

> **Aclaración:** los términos `componente` y `artefacto` son sinónimos de proyecto.

## Identificación de un proyecto Gradle

Todo proyecto en Gradle tiene tres cosas que lo identifican:

- **group**: representa la organización autora/dueña del artefacto. Por ejemplo, los proyectos de Algoritmos 2 suelen usar el groupId `ar.edu.unsam.algo2`.
- **artifact**: este campo define el nombre por el que se conoce al proyecto en sí mismo. Algunos ejemplos: `commons-collections`, `eg-seguros-kotlin`, `tp-futbol5-grupo01`, etc.
- **version**: es el último componente del rompecabezas, dado que groupId:artifactId denota un único proyecto pero no alcanza para definir en qué versión del proyecto nos estamos parando. Se agrega entonces un número de versión para completar la información que Gradle necesita para generar una identificación unívoca. Conviene seguir las reglas de [**versionado semántico**](https://semver.org/), para liberar versiones productivas. A veces se suele acompañar de un sufijo `RELEASE` (para versiones estables) o `SNAPSHOT` (para versiones intermedias que pueden estar sujetas a cambios).

Gradle tomó de Maven, su antecesor directo, esta misma forma de identificar un proyecto. Vemos cómo se definen estos valores en el archivo `build.gradle.kts`:

```kotlin
group = "ar.edu.unsam.algo2"
version = "1.0-SNAPSHOT"
```

El artifact se define en el archivo `settings.gradle`:

```kotlin
rootProject.name = "eg-seguros-kotlin"
```

# Manejo de dependencias

## Repositorios locales

Las **dependencias** son útiles para poder acceder a códigos escritos por otros (como la biblioteca [Mockk](https://mockk.io/) o [Apache Commons Collections](https://commons.apache.org/proper/commons-collections/)). Para facilitar la descarga de esa dependencia, se suben como **artefacto** con diferentes números de versión a un **repositorio**. Cuando instalamos Gradle, se crea un repositorio local en una carpeta que por defecto suele ser `HOME/.gradle`. Podemos encontrar al componente cuyo identificador es `io.kotest:kotest-assertions-core:5.1.0` en

```bash
~/.gradle
   └── caches
        └── modules-2
             └── files-2.1
                    └── io.kotest
                          └── kotest-assertions-core
                                ├─ 4.4.3 (otra versión)
                                └─ 5.1.0 --> dentro de esta carpeta estará el artefacto
```

- recordemos que el identificador de un componente se arma a partir del groupId + el artifactId + la versión
- en la cache de Gradle están todos los componentes que descargamos localmente. Esto permite que cuando estemos trabajando en otro proyecto que comparta la misma dependencia no necesitemos ir a descargarla desde los repositorios. El comportamiento en una máquina Windows es exactamente igual, hay que explorar los directorios incluyendo los que son ocultos, y navegar a partir de la carpeta de usuario + `\.gradle`.

## Repositorios remotos

Ahora bien, ¿desde dónde descargamos las versiones 4.4.3 y 5.1.0 de io.kotest:kotest-assertions-core? Existen para eso **repositorios remotos** donde se publican artefactos:

- **Maven Central**, que es el repositorio principal donde están subidos artefactos publicados con tecnología [Maven](https://maven.apache.org/). Las dependencias más importantes suelen estar en este repositorio y tenés una [página de búsqueda de artefactos](https://search.maven.org/), muy útil cuando necesitamos bajarnos "Mockito", "Log4J", "Kotest" o cualquier otra dependencia.
- para los proyectos en Kotlin, otro repositorio importante es el de [**Google** (también en Maven)](https://maven.google.com/web/index.html) ya que contiene componentes relacionados con el desarrollo de Android, entre otros.
- hay eventualmente otros repositorios remotos e incluso podés crear un servidor que funcione como repositorio de artefactos. Podés investigar [Artifactory o JFrog](https://jfrog.com/artifactory/), por el momento es suficiente con saber simplemente desde dónde estamos descargando nuestros componentes.

En el archivo `build.gradle.kts` podés ver cómo se referencian los repositorios remotos:

```kotlin
repositories {
    mavenCentral()<commit_msg>Better explanation of gradle local repo<commit_after>---
layout: article
title: Introducción a Gradle
categories: [gradle, build, integración, scm]
featured: true
---

![Gradle logo](/img/wiki/gradle_logo2.png)

# Introducción

Gradle es una herramienta que ayuda a desarrollar un proyecto basado en el entorno de una JDK (Java, Kotlin, Xtend, Scala, Groovy, etc.) y que cumple con las siguientes funciones principales que vamos a explicar en las siguientes secciones:

- Reificación del Proyecto
- Manejo de Dependencias a partir de repositorios locales y remotos
- Plugins y tareas

# Reificación de Proyecto

Java no trabaja la idea de proyecto, no lo representa como concepto, y esto se traslada a todos los lenguajes basados en la JDK. Entonces, cada uno de los IDEs pensados para Java agregan su propia forma de definirlo: 

- en Eclipse tenemos los archivos `.classpath` y `.project`
- en IntelliJ tenemos el directorio oculto `.idea`
- en Visual Studio Code tenemos el directorio `.vscode`

Gradle permite trabajar en cualquiera de estos IDEs con su propio modelo de proyecto, que se guarda en el archivo `build.gradle.kts` en el caso de trabajar utilizando el lenguaje Kotlin o `build.gradle` a secas, cuando la configuración se hace utilizando el lenguaje Groovy. A partir de ahora vamos a continuar la explicación asumiendo que estás usando Gradle con Kotlin.

> **Aclaración:** los términos `componente` y `artefacto` son sinónimos de proyecto.

## Identificación de un proyecto Gradle

Todo proyecto en Gradle tiene tres cosas que lo identifican:

- **group**: representa la organización autora/dueña del artefacto. Por ejemplo, los proyectos de Algoritmos 2 suelen usar el groupId `ar.edu.unsam.algo2`.
- **artifact**: este campo define el nombre por el que se conoce al proyecto en sí mismo. Algunos ejemplos: `commons-collections`, `eg-seguros-kotlin`, `tp-futbol5-grupo01`, etc.
- **version**: es el último componente del rompecabezas, dado que groupId:artifactId denota un único proyecto pero no alcanza para definir en qué versión del proyecto nos estamos parando. Se agrega entonces un número de versión para completar la información que Gradle necesita para generar una identificación unívoca. Conviene seguir las reglas de [**versionado semántico**](https://semver.org/), para liberar versiones productivas. A veces se suele acompañar de un sufijo `RELEASE` (para versiones estables) o `SNAPSHOT` (para versiones intermedias que pueden estar sujetas a cambios).

Gradle tomó de Maven, su antecesor directo, esta misma forma de identificar un proyecto. Vemos cómo se definen estos valores en el archivo `build.gradle.kts`:

```kotlin
group = "ar.edu.unsam.algo2"
version = "1.0-SNAPSHOT"
```

El artifact se define en el archivo `settings.gradle`:

```kotlin
rootProject.name = "eg-seguros-kotlin"
```

# Manejo de dependencias

## Repositorios locales

Las **dependencias** son útiles para poder acceder a códigos escritos por otros (como la biblioteca [Mockk](https://mockk.io/) o [Apache Commons Collections](https://commons.apache.org/proper/commons-collections/)). Cuando instalamos Gradle, se crea un repositorio local en una carpeta que por defecto suele ser `HOME/.gradle`, donde descargamos los componentes localmente **una sola vez** (muchos proyectos que usan la misma dependencia van a buscar el artefacto en ese mismo lugar). Podemos encontrar al componente cuyo identificador es `io.kotest:kotest-assertions-core:5.1.0` en

```bash
~/.gradle
   └── caches
        └── modules-2
             └── files-2.1
                    └── io.kotest
                          └── kotest-assertions-core
                                ├─ 4.4.3 (otra versión)
                                └─ 5.1.0 --> dentro de esta carpeta estará el artefacto
```

- recordemos que el identificador de un componente se arma a partir del groupId + el artifactId + la versión
- en la cache de Gradle están todos los componentes que descargamos localmente. Esto permite que cuando estemos trabajando en otro proyecto que comparta la misma dependencia no necesitemos ir a descargarla desde los repositorios. El comportamiento en una máquina Windows es exactamente igual, hay que explorar los directorios incluyendo los que son ocultos, y navegar a partir de la carpeta de usuario + `\.gradle`.

## Repositorios remotos

Ahora bien, ¿desde dónde descargamos las versiones 4.4.3 y 5.1.0 de io.kotest:kotest-assertions-core? Existen para eso **repositorios remotos** donde se publican artefactos:

- **Maven Central**, que es el repositorio principal donde están subidos artefactos publicados con tecnología [Maven](https://maven.apache.org/). Las dependencias más importantes suelen estar en este repositorio y tenés una [página de búsqueda de artefactos](https://search.maven.org/), muy útil cuando necesitamos bajarnos "Mockito", "Log4J", "Kotest" o cualquier otra dependencia.
- para los proyectos en Kotlin, otro repositorio importante es el de [**Google** (también en Maven)](https://maven.google.com/web/index.html) ya que contiene componentes relacionados con el desarrollo de Android, entre otros.
- hay eventualmente otros repositorios remotos e incluso podés crear un servidor que funcione como repositorio de artefactos. Podés investigar [Artifactory o JFrog](https://jfrog.com/artifactory/), por el momento es suficiente con saber simplemente desde dónde estamos descargando nuestros componentes.

En el archivo `build.gradle.kts` podés ver cómo se referencian los repositorios remotos:

```kotlin
repositories {
    mavenCentral()
{'fraction_non_alphanumeric': 0.07488228902571532, 'fraction_numerical': 0.0050706265845708075, 'mean_word_length': 4.2595238095238095, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 7, 'https://': 14, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '7023567', 'n_tokens_mistral': 3565, 'n_tokens_neox': 3469, 'n_words': 1413}