Как получить следующий номер сборки в Gradle

есть ли способ получить следующую версию при публикации в репозитории в gradle?

например, если у меня версия 3.0.1 в моем репозитории я хочу, чтобы опубликованная версия была 3.0.2.

ivy есть задача ant имени buildnumber что делает именно это:

<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>

есть ли способ сделать это в gradle? если нет, как я могу получить доступ ivy задачи от gradle ant?

в своем build.gradle Я взываю к ant

ant.importBuild 'build.xml'
27
ant gradle ivy java

5 ответов

Я не думаю, что есть поддержка в Gradle, но вы можете попробовать использовать Ant-задачу. https://docs.gradle.org/current/userguide/ant.html#sec:import_ant_build

другой способ сделать это-использовать какой-то плагин или настроить задачу для управления версией.

9

Да, вы можете получить доступ к задачам ivy из сценария ant, импортировав сборку ant.xml-файл для сборки gradle.файл gradle. Ниже приведен синтаксис для этого.

ant.сборка importBuild.с XML'

обращайтесь : https://docs.gradle.org/current/userguide/ant.html#sec:import_ant_build

7

Я рекомендую вам использовать плагин ResearchGate release https://github.com/researchgate/gradle-release У него есть довольно документация. Легко читать. Кроме того, проверьте, как я использовал его в своем личном проекте. https://github.com/vatolinrp/bitcoin-esb/blob/master/build.gradle Это был бы хороший пример для вас.

5

после долгой работы мне удалось это сделать.

в своем построить.Gradle в я добавил следующий код

ant.importBuild 'build.xml'

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

я импортировал мой ant построить файл и создать задачу, которая вызывает ivy buildnumber задач.

вот мой построить.в 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>

потому что у моей IDE (Intellij) не было ivy.jar на содержание
Я импортировал ivy.jar из моего корневого каталога (lib/ivy.jar)

4
  • для этого точного поведения, Плющева buildnumber задача может быть вызвана с помощью чистого Gradle без импорта сборки 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
    }
}

  • В общем, Gradle не имеет в комплекте эквивалента плагина Maven Release, поэтому приходится полагаться на Плагины. Один сплошной плагин ш -выпуск по ResearchGate, другой Аксион "Аллегро" технологий. Бывший классический Мэйвен стиле управлении последний принимает SCM как единственный источник истины, устраняя управление версиями в файлах сборки. Но ни один из этих плагинов не предоставляют точной поведение.

  • мое личное мнение по проблеме управления версиями изначально нужно было использовать некоторые плагины. Поскольку я использую Bamboo в качестве CI-сервера на работе, буквально все, что я делал с плагинами выпуска, используя Gradle, рано или поздно разбилось на CI-сервере. Это могло бы работать в течение нескольких недель, но каждый сервер обновление принесло некоторые проблемы. Я закончил использование SCM-менее подхода с простым соглашением: используйте имя ветви в качестве базовой версии, объедините его с номером сборки (оба значения предоставляются сервером CI):

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

CI-сервер затем можно настроить для выполнения следующей команды

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

когда кнопка "Release" нажата. Например, сборка 12 ветви 3.0 будет производить версию 3.0.12 в двоичном репозитории.

в преимуществами являются:
+ версия поставляется бесплатно, предполагая, что ветви названы соответственно
+ автоматически увеличенный номер сборки также поставляется бесплатно
+ можно легко публиковать пользовательские версии
+ отсутствие плагинов означает отсутствие проблем с обновлениями версии Gradle
+ этот подход смертельно прост и всегда работает

минусы:
- нет тегов (никаких изменений в SCM-нет ветвей выпуска и т. д.), но так как номер сборки всегда известно, что можно просмотреть ревизию в истории сборки CI
- некоторые номера сборки будут пропущены, очевидно (например, следующая версия после 3.5.76 может быть 3.5.84)

1