Вопрос:
У меня есть следующие файлы, которые я хотел бы загрузить в Artifactory как артефакт с версией 9.8.0.
ПРИМЕЧАНИЕ. Первые два файла НЕ имеют расширения (это исполняемые файлы, т.е. Если вы откроете их /cat на нем, вы увидите ненужные символы).
Папка/файлы данной версии 9.8.0 в CVS выглядит так:
com.company.project/gigaproject/v9.8.0/linux/gigainstall com.company.project/gigaproject/v9.8.0/solaris/gigainstall com.company.project/gigaproject/v9.8.0/win32/gigainstall.exe com.company.project/gigaproject/v9.8.0/gigafile.dtd com.company.project/gigaproject/v9.8.0/gigaanotherfile.dtd com.company.project/gigaproject/v9.8.0/giga.jar com.company.project/gigaproject/v9.8.0/giga.war
Загрузка указанных выше файлов с расширением очень проста… Вы входите в Artifactory как администратор/пользователь, у которого есть доступ к развертыванию артефактов, нажимаете на вкладку “Deploy”, ищите файл Artifactory и после выбора файла нажмите на кнопку “Загрузить”.
Далее вы увидите экран (как показано выше). Вы настроите то, что хотите, в полях на этой странице, и как только вы нажмете “Развернуть артефакт”, все готово. Все, что вам нужно, это убедиться, что вы выбрали правильный файл file.extension при загрузке и убедитесь, что расширение файла отображается правильно в поле “Целевой путь” (с версией -x.xx и т.д.).
Мои вопросы:
Вопрос 1: Как загрузить артефакт, который не имеет расширения? Похоже, что Artifactory по умолчанию принимает артефакт как расширение .jar. Как я могу загрузить артефакт “gigainstall”, как показано выше в структуре папок/файлов для Linux и Solaris? Я вижу, что могу использовать имя артефакта как gigainstall-linux и gigainstall-solaris и дифференцировать его, но я не уверен, как сказать Artifactory, что этот артефакт не имеет никакого расширения.
Я не думаю, что команда разработчиков начнет генерировать этот артефакт с соответствующим расширением (поскольку этот артефакт может быть жестко запрограммирован везде в других проектах, где они в настоящее время получают его из системы контроля версий CVS/SVN где-то – что само по себе является плохой практикой сохранить артефакт в инструменте управления версиями).
Вопрос 2: Как я скажу системе сборки (например, Gradle) потреблять нерасширенный артефакт во время, скажем, задачи ‘compile’. В build.gradle в разделе зависимости {..} я добавлю что-то вроде того, что показано ниже, но я не уверен для файлов без расширений (первые два в структуре папок/файлов, которые я упомянул выше).
dependencies { //compile ‘com.company.project:gigainstall-linux:9.8.0@’ //compile ‘com.company.project:gigainstall-linux:9.8.0@??????’ //compile ‘com.company.project:gigainstall-linux:9.8.0@»»‘ //compile ‘com.company.project:gigainstall-linux:9.8.0@»none»‘ //compile ‘com.company.project:gigainstall-linux:9.8.0@»NULL_or_something»‘ // The following will easily get giga.jar version giga-9.8.0.jar from Artifactory repository compile ‘com.company.project:giga:9.8.0’ // The following will easily get giga.war compile ‘com.company.project:giga:9.8.0@war’ // Similarly, other extension based artifacts can be fetched from Artifactory compile ‘com.company.project:gigafile:9.8.0@dtd’ compile ‘com.company.project:gigaanotherfile:9.8.0@dtd’ } Лучший ответ:
Ответ 1 (также будет охватывать 2 в другом смысле): Использование раздела функций Artifactory “Buildle” на вкладке “Deploy” может сделать TRICK для ПОСЛЕДНЕЙ ЗАГРУЗКИ артефактов так, как мы хотим, сначала создав zip файл ( содержит структуру и артефакты в ней) –OR вы можете загружать артефакты, используя/вызывая Artifactory REST API.
Идея высокого уровня:
Создайте zip файл с именем gigaproject.zip ИЛИ anyname.zip/.tar/compressed, который может прочитать Artifactory. Внутри zip создайте структуру – как эти артефакты будут загружены в Artifactory
т.е. gigaproject.zip будет содержать следующие папки/структуры/файлы.
Случай 1:
com/company/project/gigaproject/9.8.0/linux/gigainstall com/company/project/gigaproject/9.8.0/solaris/gigainstall com/company/project/gigaproject/9.8.0/win32/gigainstall.exe com/company/project/gigaproject/9.8.0/gigafile.dtd com/company/project/gigaproject/9.8.0/gigaanotherfile.dtd com/company/project/gigaproject/9.8.0/giga.jar com/company/project/gigaproject/9.8.0/giga.war
ПРИМЕЧАНИЕ: в примере 1 я не использовал ни одного -x.xx в имени файла (т.е. я использую простой и простой giga.jar вместо giga-9.8.0.jar).
Приведенная выше загрузка/развертывание приведет к получению файлов (как показано на следующем снимке):
Итак, мы добились того, что хотели. На самом деле (очевидно, да), но не таким образом, как Artifactory обычно сохраняет эти артефакты (как они должны -x.xx версия встроена в имя файла и где идентификатор артефакта должен совпадать с именем файла артефакта). Теперь, если вы хотите использовать следующее в файле сборки Gradle, вы НЕ МОЖЕТЕ, во-первых, вы не загрузили имя файла с именем версии -x.xx в нем, во-вторых, идентификатор артефакта в нашем дереве case 1 был ” gigaproject “(после папки com/company/project), поэтому Gradle способ определить, какой идентификатор артефакта и какое имя файла артефакта вы хотите, не будет работать.
compile ‘com.company.project:gigaproject:CANNOTSAY_HOW_TO_GET_GIGA_JARorGIGAINSTALL_with_without_extension’
Вывод: можно загружать любые файлы (с/без расширения в Artifactory) в любой структуре, но это зависит от того, как ваша сборочная система будет использовать его или сможет использовать или нет. – Я удалил структуру, которую я только что создал с файлом .zip дела 1, из хранилища Artifactory, чтобы попробовать следующий случай # 2, и удалил файл .zip, который я создал.
Случай 2:
Давайте создадим индивидуальное версионное имя файла для каждого артефакта, а также создадим структуру в формате – как на самом деле Artifactory хранит их (артефакт, видимый в репозитории в виде дерева) и создайте файл .zip, содержащий эту структуру. Давайте использовать ту же функцию “Artifact Bundle”, чтобы загрузить этот файл .zip для загрузки отдельных артефактов, которые нам нужны в Artifactory – где id-артефакт (второе значение, которое мы упоминаем при попытке использовать его) будет соответствовать имени файла артефакта в Artifactory.
Структура папок/файлов для файла .zip:
com/company/project/gigainstall/9.8.0/gigainstall-9.8.0.linux com/company/project/gigainstall/9.8.0/gigainstall-9.8.0.solaris com/company/project/gigainstall/9.8.0/gigainstall-9.8.0.exe com/company/project/gigafile/9.8.0/gigafile-9.8.0.dtd com/company/project/gigaanotherfile/9.8.0/gigaanotherfile-9.8.0.dtd com/company/project/giga/9.8.0/giga-9.8.0.jar com/company/project/giga/9.8.0/giga-9.8.0.war
ПРИМЕЧАНИЕ. На этот раз мы будем использовать ту же функцию “Artifact Bundle”, и для похожих файлов (gigainstall в обеих папках Linux/Solaris) я использовал подход к созданию папки gigainstall (содержащей gigainstall-9.8.0.linux и gigainstall). -9.8.0.solaris имена файлов) т.е. когда мы будем использовать эти артефакты в Gradle в разделе зависимостей {…} для компиляции, мы будем использовать способ xxx @для извлечения этих артефактов из Artifactory.
Хорошо, после успешного развертывания/выгрузки “Artifact Bundle” я получил следующее сообщение.
Successfully deployed 7 artifacts from archive: gigaproject.zip (1 seconds).
Теперь давайте посмотрим, как это выглядит в Artifactory при поиске одного из артефактов/в виде дерева. Вы можете видеть, что у нас теперь есть файлы с именем файла -x.xxextension, так что я могу легко использовать их в Gradle.
В файле сборки Gradle (build.gradle) я упомяну:
dependencies { compile «com.company.project:gigainstall:9.8.0@linux» compile «com.company.project:gigainstall:9.8.0@solaris» compile «com.company.project:gigainstall:9.8.0@linux» compile «com.company.project:giga:9.8.0 compile «com.company.project:giga:9.8.0@war compile «com.company.project:gigafile:9.8.0@dtd compile «com.company.project:gigaanotherfile:9.8.0@dtd }
ОЙ ОЙ!! – Это не сработало, см. Ниже об ошибке Gradle. Зачем? – Функция выгрузки/развертывания Artifactory Bundle загружает содержимое файла zip, имеющееся в .zip, но НЕ создает файл .pom для каждого развернутого артефакта. Таким образом, сборка Gradle не удалась. Может быть, в муравье это может быть успешно Это происходило для каждого отдельного файла .jar/.war/.dtd/etc. Я просто показываю один пример ошибки.
Пока занимаюсь чисткой сборкой
Could not resolve all dependencies for configuration ‘:compile’. > Could not resolve com.company.project:gigafile:0.0.0. Required by: com.company.project:ABCProjectWhichConsumesGIGAProjectArtifacts:1.64.0 > Could not GET ‘http://artifactoryserver:8081/artifactory/ext-snapshot-local/com/company/project/gigafile/0.0.0/gigafile-0.0.0.pom’. Received status code 409 from server: Conflict
Случай 3: давайте возьмем простой подход (обходной путь, но сэкономит много боли). Создайте файл gigaproject.zip со следующей структурой, этот подход принимает следующее. Нет значения версии xxx, встроенного в отдельный артефакт/имя файла в структуре папок/файлов. Мы будем использовать подход “Единый артефакт” (который автоматически создаст файл .pom для gigaproject.zip во время процесса загрузки/развертывания, предоставляемого Artifactory). Используя этот подход, вы все равно сможете получить файл gigainstall без необходимости расширения его имени. На этапе загрузки/развертывания, как вы уже видели, вы загружаете файл gigaproject.zip, а артефакт загружает его в заданный целевой репозиторий как “gigaproject -x.xxzip”, где xxx в нашем случае – 9.8.0. Смотрите снимок изображения ниже.
gigaproject/linux/gigainstall gigaproject/solaris/gigainstall gigaproject/win32/gigainstall.exe gigaproject/gigafile.dtd gigaproject/gigaanotherfile.dtd gigaproject/gigaproject.zip gigaproject/giga.jar gigaproject/giga.war
Теперь загрузите его в Artifactory, используя функцию “Single Artifact”. Нажмите “Развернуть артефакт” после настройки значений GroupId, ArtifactId, Version и т.д.
Как только это загружено. Вы увидите в zip-артефакте в целевом репозитории (я привел плохой пример, обычно это будет libs-snapshot-local или libs-release-local вместо ext-…), вы сможете использовать артефакт ZIP непосредственно в Graddle:
dependencies { // This is the only line we need now. compile «com.company.project:gigaproject:9.8.0@zip» }
Как только .zip станет доступным для системы сборки Gradle, теперь вы можете сказать Gradle распаковать этот файл .zip где-нибудь в вашей области сборки/рабочей области, где вы можете подавать фактические (распакованные) файлы (gigainstall,.dtd,.jar,.war и т.д.) к процессу/этапам сборки.
PS: Случай 1 и 2 сработал бы для Муравья, я думаю.
Ответ 2: Если вы загрузили файл без расширения каким-либо образом. Убедитесь, что вы вручную создали/загрузили его POM файл (т.е. если я загрузил gigainstall-9.8.0 в качестве артефакта в com/company/project/gigainstall/9.8.0/gigainstall-9.8.0, то на том же уровне Я должен/должен создать его POM файл (см. Простой шаблон .pom файл для пользовательского артефакта jar или при загрузке расширенного файла через развертывание “Single Artifact” вы увидите то, что показывает окно POM Editor) и загрузить оба так что Gradle не ошибется, говоря, что нет конфликта/ошибки POM. Ant может не понадобиться pom (я этого не проверял).
Как только он появится в Artifactory, должна работать следующая строка – ИЛИ прокомментируйте, пожалуйста, если вы найдете другой способ.
dependencies { // See nothing mentioned after — x.x.x@ compile «com.company.package:gigainstall:9.8.0@» }
