Categoría: gradle

Recomendación SDKMAN

SDKMAN es una herramienta genial que nos permite gestionar diferentes instalaciones de herramientas relacionadas con el mundo Java (JDK, Maven, Gradle, SpringBoot, …) desde la línea de comandos. Lo que es muy práctico es que permite que convivan, de forma muy fácil, diferentes versiones de estas herramientas.

$ sdk current

Using:

gradle: 3.4.1
grails: 3.2.7
groovy: 2.4.10
kotlin: 1.1.1
maven: 3.3.9
sbt: 0.13.13
scala: 2.12.1
springboot: 1.5.2.RELEASE

Si no lo estáis usando ya, os recomiendo que le echéis un ojo.

Saludos

Gradle, Sonar e Informes de cobertura (Jacoco)

Para un proyecto java simple.

El análisis estático de SonarQube se lanza desde Jenkins.

sonar-project.properties:

sonar.projectKey=com.sourcerebels:some_project
sonar.projectName=SomeProject
sonar.projectVersion=1.0
sonar.language=java
sonar.sources=src/main/java
sonar.tests=src/test/java
sonar.java.binaries=build/classes/main
sonar.jacoco.reportPaths=build/jacoco/test.exec

build.gradle

apply plugin: 'java'
apply plugin: 'application'
apply plugin: 'jacoco'

mainClassName = "SomeProject"
sourceCompatibility = 1.8
targetCompatibility = 1.8

repositories {
    jcenter()
    mavenCentral()
}

dependencies {
    testCompile 'junit:junit:4.12'
    testCompile 'org.mockito:mockito-core:2.7.16'
}

JitPack.io mola mucho

Hace ya un tiempo que vengo siguiendo este servicio (he visto que mucha gente lo va utilizando). No voy explicar nada del otro mundo, simplemente quiero recomendar su uso.

JitPack.io es un servicio que permite publicar un tag concreto de un repositorio de Github en su repositorio de Maven.

El esfuerzo necesario para publicar i/o utilizar una librería de Android es tan poco que parece mentira.

Este repositorio es compatible con los sistemas de construcción: Maven (Java), Gradle (Java, Android, Groovy), SBT (Scala) o Leiningen (Clojure).

Mola mucho. Buen trabajo 🙂

Mostrar el resultado de los test unitarios al ejecutar Gradle

Una de las cosas que me confunde cuando ejecuto el Gradle desde la línea de comandos es que si los tests se ejecutan sin fallos, no muestra ningún tipo de detalle acerca de que tests fueron ejecutados. Con lo que no acabo de tener la certeza de que todo haya ido bien.

Al añadir estas líneas en el fichero build.gradle de nuestro módulo mostrará la información de qué test ha ejecutado y cual ha sido el resultado, además de la salida standard y error si la hubiese.

android {
  ...
  testOptions.unitTests.all {
    ignoreFailures false
    testLogging {
      events "passed", "skipped", "failed", "standardOut", "standardError"
    }
  }
}

Por supuesto, yo no he inventado nada. Lo saqué de esta respuesta en Stackoverflow.

Tema relacionado: Test from the Command Line

Centralizar las versiones de las librerías utilizadas por Gradle

Cuando tenemos un proyecto con varios módulos, a veces, nos interesa tener un lugar centralizado dónde definir las versiones de las librerías que utilizaremos.

De esta manera, si varios módulos del proyecto, utilizan la misma librería nos aseguraremos que todos estén usando la misma versión.

En el fichero build.gradle de la carpeta raíz, en el apartado “ext”, definiremos las versiones a utilizar:

ext {
    supportLibrary = '24.2.0'
    googlePlayServices = '9.4.0'
    junit = '4.12'
}

En el fichero build.gradle de cada uno de los módulos, en el apartado “dependencies”, haremos referencia a las versiones definidas de la siguiente manera:

dependencies {

    def versions = rootProject.ext

    compile fileTree(dir: 'libs', include: ['*.jar'])
    testCompile "junit:junit:" + versions.junit
    androidTestCompile "junit:junit:" + versions.junit
    compile "com.android.support:appcompat-v7:" + versions.supportLibrary
    compile "com.android.support:design:" + versions.supportLibrary
    compile "com.google.android.gms:play-services-maps:" + versions.googlePlayServices
    compile "com.google.android.gms:play-services-location:" + versions.googlePlayServices
}

SonarQube

Para poder analizar un proyecto Android con la herramienta sonarqube tuve que modificar el fichero build.gradle añadiendo las siguientes líneas:

buildscript {
  repositories {
    ...
    maven { url "https://plugins.gradle.org/m2/" } 
  }
  dependencies {
    ...
    classpath "org.sonarsource.scanner.gradle:sonarqube-gradle-plugin:1.2"
  }
}

apply plugin: 'org.sonarqube'

sonarqube {
  properties {
    ...
    property "sonar.projectName", "Mi aplicación"
    property "sonar.host.url", "http://url_de_sonarqube"
    properties["sonar.sources"] += "src"
  }
}

Ocultar las credenciales de TestFairy a ojos curiosos

Como me resulta muy molesto tener que ir actualizando el número de versión cada vez que quiero subir un apk, últimamente vengo usando TestFairy y su plugin para Gradle.

La verdad es que funciona maravillosamente bién, pero siguiendo las instrucciones de la página del plugin parece que tuvieras que subir las credenciales (apiKey) en el repositorio de código fuente.

Para ello crearemos un fichero gradle.properties. Yo lo he puesto en la ruta $HOME/.gradle/gradle.properties pero puedes ponerlo en otros sitios.

$ cat $HOME/.gradle/gradle.properties
MyProjectTestFairyApiKey=blahblahblahblah

Es interesante conocer que todas las propiedades que pongamos aquí, estarán disponibles en el script de Gradle automáticamente.

En el build.gradle dónde va la api key, ponemos el nombre de la preferencia que acabamos de definir en el otro fichero:

testfairyConfig {
	apiKey MyProjectTestFairyApiKey
	...
}

De esta forma, no tendremos que compartir las credenciales con todo el mundo que tenga acceso al código fuente.

Saludos

Android Product Flavors

En muchas ocasiones, cuando desarrollemos una app de Android, nos interesará generar diferentes variantes de una misma app. Por ejemplo, en el caso de nuestra aplicación deba consumir uno json proporcionado por un servicio en la red, tendrémos un servidor para pruebas y un servidor de producción.

Para ello usamos Product Flavors, una funcionalidad del sistema de construcción Gradle de Android.

En el fichero build.gradle de nuestra app añadiremos:

	productFlavors {
		
		dev {
			applicationId "com.sourcerebels.flavors.dev"
			resValue "string", "service_url", "http://dev.example.com"
		}
		production {
			applicationId "com.sourcerebels.flavors.production"
			resValue "string", "service_url", "http://www.example.com"
		}
	}

Ahora, desde la ventana “Build Variants” de Android Studio, seleccionaremos que variante queremos construir.

Tambíen podemos hacerlo con gradle desde la línea de comandos. Por ejemplo:

	gradle module:assembleDevDebug
	gradle module:assembleProductionRelease

Flavors nos permite además personalizar recursos o assets. Para ello es tan simple como crear las carpetas src/flavor/res, src/flavor/assets y src/flavor/java.

Por ejemplo, si quisiesemos personalizar los colores o un recurso de la app en función de la variante, personalizaríamos los siguientes ficheros:

	src/dev/res/values/colors.xml
	src/dev/res/drawable/some_resource.xml

	src/production/res/values/colors.xml
	src/production/res/drawable/some_resource.xml

Parece que vamos a usar mucho esta funcionalidad de ahora en adelante.