TLDR: используйте классификаторы.
Поскольку вы публикуете в Maven, давайте прочитаем их документы о Координаты Maven :
POM, определенный выше, - это тот минимум, который позволяет Maven. groupId:artifactId:version все обязательные поля (хотя groupId и version не нужно явно определять, если они унаследованы от родителя - подробнее о наследовании позже). Эти три поля очень похожи на адрес и временную метку в одном. Это отмечает конкретное c место в репозитории, действующее как система координат для проектов Maven:
- groupId : Это, как правило, уникально для организации или проекта. Например, все основные артефакты Maven (ну, должны) живут под groupId
org.apache.maven. Идентификаторы групп не обязательно используют точечную нотацию, например, проект junit. Обратите внимание, что точка-точка groupId не обязательно должна соответствовать структуре пакета, содержащейся в проекте. Это хорошая практика для подражания. При хранении в репозитории группа действует так же, как структура упаковки Java в операционной системе. Точки заменяются разделителями каталогов, определяемыми ОС c (такими как '/' в Unix), которые становятся относительной структурой каталогов из базового репозитория. В данном примере группа org.codehaus.mojo находится в каталоге $M2_REPO/org/codehaus/mojo. - artifactId : artifactId - это, как правило, имя, которому известен проект. Хотя groupId важен, люди в группе редко будут упоминать groupId в обсуждении (они часто имеют одинаковый идентификатор, такой как MojoHaus project groupId:
org.codehaus.mojo). Вместе с groupId он создает ключ, который отделяет этот проект от любого другого проекта в мире (по крайней мере, так и должно быть :)). Наряду с groupId, artifactId полностью определяет жилые помещения артефакта в хранилище. В случае вышеупомянутого проекта my-project живет в $M2_REPO/org/codehaus/mojo/my-project. - версия : это последняя часть головоломки имен.
groupId:artifactId обозначает отдельный проект, но они не могут определить, о каком воплощении того проекта мы говорим. Хотим ли мы junit:junit 2018 года (версия 4.12) или 2007 года (версия 3.8.2)? Вкратце: изменения кода, эти изменения должны быть версионными, и этот элемент поддерживает эти версии в соответствие. Он также используется в хранилище артефакта для отделения версий друг от друга. my-project файлы версии 1.0 находятся в структуре каталогов $M2_REPO/org/codehaus/mojo/my-project/1.0.
Три элемента, приведенные выше, указывают на конкретную c версию проекта, позволяя Maven знать, с кем мы имеем дело, и когда в его жизненном цикле программного обеспечения мы хотим их.
Понятно, что Maven Coordinates является уникальным идентификатором указанной c версии артефакта. Не может быть двух разных артефактов с одинаковыми координатами.
Единственный способ опубликовать sh два артефакта под одним artifactId - это использовать разные версии.
Если вы отметите спецификации порядка версий , вы увидите, что вы можете использовать так называемые квалификаторы, такие как 1.0.0-ALPHA, 1.0.0-RC. Так на самом деле Javadocs и источники публикуются в репозиториях Maven: для артефакта с координатами a.b.c:d:1.0.0 могут быть опубликованы Javadocs в a.b.c:d:1.0.0-javadoc и источники в a.b.c:d:1.0.0-sources.
. Поэтому используйте квалификаторы для выполнения трюк.
Квалификаторы указаны на стороне артефактов в Gradle:
publishing {
publications {
myPublication(MavenPublication) {
groupId 'com.example.project'
version '1.0.2'
artifactId 'myProject'
artifact("$buildDir/outputs/aar/mySDK-release-2.aar") {
// These values can also be specified in the task that generates the AAR.
classifier "q1"
}
artifact("$buildDir/outputs/aar/mySDK-release-1.aar") {
classifier "q2"
}
}
}
}