vmoptions studio rendimiento optimizar memoria mejorar mas lite emulador dar aumentar aplicacion java gradle ant ivy

java - studio - Cómo obtener el siguiente número de compilación en Gradle



rendimiento de android studio (5)

Después de un largo trabajo, logré hacer eso.

En mi build.gradle agregué este siguiente código

ant.importBuild ''build.xml'' task getNextBuild(dependsOn : ivyBuildNumber) { doLast{ def nextVersion = ant.properties[''ivy.new.revision''] println nextVersion } }

Importé mi archivo de compilación ant y creé una tarea que llama a la tarea de buildnumber ivy .

Ahí está mi build.xml

<project xmlns:ivy="antlib:org.apache.ivy.ant"> <target name="ivyBuildNumber"> <path id="ivy.classpath" path="lib/ivy.jar" /> <typedef resource="org/apache/ivy/ant/antlib.xml" uri="antlib:org.apache.ivy.ant" classpathref="ivy.classpath" /> <ivy:buildnumber organisation="daniel" module="hello"/> <echoproperties prefix="ivy.new."/> </target> </project>

Debido a que mi IDE (Intellij), no tenía ivy.jar en el contenido,
ivy.jar el ivy.jar desde mi directorio raíz ( lib/ivy.jar )

¿Hay alguna forma de obtener la próxima versión al publicar en un repositorio en gradle?

Por ejemplo, si tengo la versión 3.0.1 en mi repositorio, quiero que la versión publicada sea 3.0.2 .

ivy tiene una tarea para la ant denominada buildnumber que hace exactamente eso:

<project xmlns:ivy="antlib:org.apache.ivy.ant" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <target name="ivyBuildNumber" description="Use ivy get the next build number"> <ivy:buildnumber resolver="url-chain" organisation="${ivy.organisation}" module="${ivy.module}" revision="${version.base}"/> <echoproperties prefix="ivy.new."/> </target>

¿Hay una manera de hacerlo en gradle ? Si no, ¿cómo puedo acceder a las tareas de ivy de la ant de Gradle?

En mi build.gradle llamo a la ant

ant.importBuild ''build.xml''





  • Para este comportamiento exacto , la tarea Ivy buildnumber puede invocarse usando Gradle puro sin importar la compilación Ant:

configurations { antTasks // define a new configuration } repositories { mavenCentral() } dependencies { antTasks("org.apache.ivy:ivy:2.4.0") // add Ivy library to it } ext { // define the Ivy task, using the extra configuration as classpath extension ant.taskdef(name: "ivyBuildNumber", classname: "org.apache.ivy.ant.IvyBuildNumber", classpath: configurations.antTasks.asPath) ant.ivyBuildNumber(organisation: "daniel", module: "hello") nextVersion = ant.properties["ivy.new.revision"] } task demo { doLast { println nextVersion } }

  • En general , Gradle no tiene ningún paquete equivalente a Maven Release Plugin, por lo que uno tiene que confiar en los plugins. Un complemento sólido es https://github.com/researchgate/gradle-release de ResearchGate, el otro es axion de Allegro Tech. El primero es el versionado clásico al estilo Maven, el último toma a SCM como la única fuente de verdad, eliminando el versionado en los archivos de compilación. Pero ninguno de estos complementos proporciona el comportamiento exacto solicitado.

  • Mi opinión personal sobre el problema de las versiones inicialmente fue usar algunos complementos. Ya que uso Bamboo como servidor de CI en el trabajo, literalmente todo lo que hice con los complementos de lanzamiento que usan Gradle se estrelló en el servidor de CI, tarde o temprano. Puede que haya funcionado durante algunas semanas, pero cada actualización del servidor trajo algunos problemas. Terminé usando el enfoque de SCM-less con una convención simple: usar el nombre de la rama como versión base, concatenarla con el número de compilación (ambos valores son proporcionados por el servidor de CI):

ext { branch = System.getProperty("branch", "develop") buildNumber = System.getProperty("buildNumber", "latest") isRelease = System.getProperty("isRelease", "false").toBoolean() artifactVersion = "${branch}${(isRelease ? ".$buildNumber" : "-SNAPSHOT")}" }

El servidor CI se puede configurar para ejecutar el siguiente comando

./gradlew -DisRelease=true -Dbranch=${git.branch} -DbuildNumber=${build.number} mavenPublish

cuando se presiona el botón ''Release''. Por ejemplo, la compilación 12 de la rama 3.0 producirá la versión 3.0.12 en el repositorio binario.

Las ventajas son:
+ la versión viene gratis, asumiendo que las ramas son nombradas en consecuencia
+ el número de compilación auto-incrementado también viene gratis
+ Uno puede publicar fácilmente revisiones personalizadas
+ sin complementos significa que no hay problemas con las actualizaciones de la versión Gradle
+ este enfoque es muerto simple y siempre funciona

Las desventajas son:
- sin etiquetas (sin cambios en SCM - sin sucursales de lanzamiento, etc.), pero como el número de compilación siempre se conoce, se puede ver la revisión en el historial de compilaciones de CI
- algunos números de compilación se omitirán, obviamente (por ejemplo, la próxima versión después de 3.5.76 puede ser 3.5.84)