Обновление Gradle 5.1.1 до 6.0.1 ломает мультиплатформенную сборку Kotlin

Я обновил свой мультиплатформенный проект Kotlin, чтобы использовать Gradle 6.0.1:

gradle wrapper --gradle-version 6.0.1 --distribution-type all

и теперь моя сборка ломается. Он не распознает общие модули, которые я добавляю в качестве зависимости к моему проекту:

dependencies {
    commonMainApi("mygroup:mylib:$myversion")
}

Я использую Kotlin DSL, и этот проект также является мультиплатформенным. Я получаю стену с текстом, в котором подробно описывается весь импорт, который не может быть разрешен (предполагается, что все они импортируются из модуля common в моей зависимости от модуля common в моем проекте).

Единственное, что я сделал, - это обновился до Gradle 6.0.1. Если я восстановлю предыдущее состояние, моя сборка будет в порядке. Что я делаю неправильно?


person Adam Arold    schedule 19.12.2019    source источник


Ответы (1)


Скорее всего, это связано с тем, что Gradle 6.0+ не запрашивает *.module файлы метаданных из репозитория, если *.pom модуля не содержит специальный маркер, который отсутствовал в *.poms, опубликованных с более старыми версиями Gradle (до 5.3, Я считаю)

Эти *.module файлы метаданных необходимы для правильной интерпретации одной зависимости как общих метаданных кода, используемых для анализа общих источников вашего проекта, так и специфичных для платформы артефактов, на основе которых построены ваши цели. Без этого зависимость разрешается для корневого модуля библиотеки, у которого вообще нет артефактов.

Чтобы исправить это на стороне потребителя, вы можете заставить Gradle запрашивать эти *.module файлы метаданных, добавив этот оператор в объявление репозитория в ваших сценариях сборки:

repositories {
    jcenter { 
        metadataSources { 
            gradleMetadata()
            mavenPom() 
        }
    }
    // or, if you are using a custom Maven repository:
    maven("https://my.repo.com") { 
        metadataSources { 
            gradleMetadata()
            mavenPom() 
        } 
    }
}

В документации Gradle: Поддерживаемые источники метаданных


UPD: JitPack, похоже, удаляет маркер метаданных модуля Gradle (<!-- do_not_remove: published-with-gradle-metadata -->) из POM, в результате чего Gradle не запрашивает *.module файлы метаданных. Также можно использовать аналогичный способ обхода, описанный выше.

person hotkey    schedule 19.12.2019
comment
Библиотека, которую я использую, была опубликована мной сегодня, и в ней используется Gradle 6.0.1. Это что-нибудь меняет? - person Adam Arold; 19.12.2019
comment
Другими словами: что мне делать в моем другом проекте (который я публикую), чтобы он заработал (в котором используется 6.0.1)? - person Adam Arold; 19.12.2019
comment
@AdamArold Я никогда не встречал ничего подобного с библиотеками, опубликованными с помощью Gradle 5.3+, поэтому мне не очевидно, почему это могло произойти. Опубликован ли файл *.module для корневого модуля вашей библиотеки (без суффикса в имени)? Указываете ли вы идентификатор этого модуля в качестве зависимости? Вы использовали enableFeaturePreview("GRADLE_METADATA") с Gradle до 6.0? - person hotkey; 19.12.2019
comment
Что также может помочь, так это понимание зависимостей Gradle: ./gradlew dependencyInsight --configuration metadataCompileClasspath --dependency=mylib - person hotkey; 19.12.2019
comment
Все мои модули имеют файл *.module в корневых проектах (проверьте здесь), и я указываю его идентификатор как зависимость. У меня также есть предварительный просмотр функции. - person Adam Arold; 19.12.2019
comment
Кстати, если я добавлю в свой проект блок metadataSources, который использует мультиплатформенную зависимость, сборка будет работать, спасибо. - person Adam Arold; 19.12.2019
comment
@AdamArold, интересно, я вижу, что POM, доступные в JitPack, не содержат маркер метаданных модуля Gradle <!-- do_not_remove: published-with-gradle-metadata -->, вы можете увидеть, что если вы сравните их с POM, опубликованными в локальном репозитории Maven. Возможно, JitPack удаляет из POM то, что считает комментарием? В этом случае может помочь использование другого репозитория Maven или сохранение маркера в JitPack. - person hotkey; 19.12.2019
comment
Это очень странно. Это многое объясняет! Я свяжусь с их поддержкой. Спасибо, что разобрались в этом! - person Adam Arold; 19.12.2019