Как работает ivy: publish?

Question

Я в полном недоумении, как должна работать муравейная задача ivy: publish.

Я ожидаю, что я делаю свою обычную сборку, которая создает кучу файлов JAR, затем я помещаю эти файлы JAR в (локальное) хранилище.

Как я могу указать, откуда брать встроенные jar-файлы и как они окажутся в хранилище?

Обновление:

<target name="publish-local" description="--> Publish Local">
    <ivy:retrieve />
    <ivy:publish resolver="local" pubrevision="${release.version}" status="release" update="true" overwrite="true">
        <artifacts pattern="${dist.dir}/[organisation]-[module].[ext]" />
    </ivy:publish>
</target>

это на самом деле работает, я не включал извлечение раньше.

Но у меня все еще есть некоторые проблемы, предположим, я хочу опубликовать 3 jars, openscada-utils.jar, openscada-utils-sources.jar и openscada-utils-javadocs.jar как openscada-utils-0.9.2.jar, openscada-utils-0.9.2-sources.jar и openscada-utils-0.9.2-javadocs.jar

Мне не совсем понятно, как собраны настоящие имена и где я могу указать, какие имена они должны получить. (Используя фрагмент выше, банки всегда называются только utils.jar).

Обновление 1:

Я заставил его работать (немного), но он все еще не чувствует себя хорошо. Каким-то образом все учебные пособия сосредоточены на зависимостях от сторонних проектов, но для меня не менее важным моментом является обработка специфичных для проекта зависимостей.

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

1. Как мне справиться с первой версией? У меня есть общий номер версии для всех подпроектов, чтобы указать, что они принадлежат друг другу (скажем, 0,9). Поэтому первая ревизия должна быть 0.9.0, но пока ничего из моих проектов не находится в моем репозитории. Как мне заставить Айви присвоить этот номер редакции.

2. В процессе разработки я хочу снова опубликовать собранные файлы, не меняя пока номер редакции.

3. Если я закончил свою работу, я хочу перенести ее в общий репозиторий (и увеличить номер редакции, скажем, с 0.9.0 до 0.9.1), каков рекомендуемый подход для этого?

4. Для реального выпуска я хочу сделать дистрибутивы с зависимостями и без, так или иначе, я предполагаю, что я могу использовать различные конфигурации для этого. Как я могу использовать это в своих интересах?

Answer 1

Вам необходимо указать «распознаватель». Что-то вроде:

<ivy:publish resolver="local" pubrevision="1.0"/>

Это контролируется шаблоном. Эта страница довольно хорошо это освещает. Похоже, вы хотите, чтобы ваш был:

<artifacts pattern="${dist.dir}/[organisation]-[module]-[revision]-[type].[ext]" />

И вам нужно будет идентифицировать три банки как артефакты в файле ivy.xml. Примерно так:

<publications>
    <artifact name="utils"/>
    <artifact name="utils" type="source"/>
    <artifact name="utils" type="javadocs"/>
</publications>

Answer 2

Для начала вам нужен файл ivy.xml.

<ivy-module version="2.0">
    <info organisation="com.example.code" module="MyProject"
         revision="${project.revision}"/>
    <configurations>
        <conf name="runtime" description="" />
        ... other config elements here...
    </configurations>

    <publications defaultconf="runtime">
        <artifact name="MyProject" type="jar" ext="jar" conf="runtime" />
    </publications>

    <dependencies>
        ...
    </dependencies>
</ivy-module>

Элемент info и публикации в ivy.xml позволяют вам пропустить различные атрибуты элементов ivy в build.xml.

Обратите внимание на $ {project.revision} в ivy.xml. Свойству присваивается стоимость в build.xml, но это, кажется, работает хорошо. Пересмотр может тогда легко иметь любое требуемое значение (например, ночные или локальные сборки).

Вот пример того, как вы можете настроить файл build.xml

<property name="project.revision" value="1.0.0"/>

...

<target name="ivy">
    <ivy:resolve />

    <!-- Possible ivy:report, ivy:retrieve and other
    elements for managing your dependencies go here -->

    <ivy:deliver conf="*(public)"/> 
</target>

<target name="publish" depends="clean, ivy, jar">
    <ivy:publish resolver="local">
        <!-- possible artifacts elements if your artifacts
        are not in standard location -->
    </ivy:publish>
</target>

...

Answer 3

Предполагается, что вы сначала запустите задачу <ivy:deliver/>. Это создает файл ivy.xml, который может использоваться репозиторием Ivy.

Когда вы используете <ivy:publish>, вы указываете, какой репозиторий вы хотите опубликовать, указав его в параметре resolver. Это должно соответствовать имени распознавателя в вашем файле ivy.settings.xml.

Вы на самом деле не указываете артефакты, но указывает, где искать артефакты для публикации. Это указывается в подзадаче <artifacts> в задаче <ivy:publish>. Например, если вы строите все в каталоге ${basedir}/target/archive, как мы, вы можете указать его так:

<ivy:publish resolver="public">
   <artifacts path="target/archive/[artifact].[ext]"/>
</ivy:publish>

Если вы хотите изменить номер версии вашего файла, вы можете использовать параметр pubrevision задачи <ivy:publish>. Это не обновит ivy.xml, но опубликует ваши jars / wars до правильной ревизии. Я предпочитаю использовать параметр pubrevision задачи <ivy:deliver> и позволить ему в любом случае создать правильный файл ivy.xml. Затем <ivy:publish> будет использовать ревизию в моем файле ivy.xml.

Вам не нужно делать <ivy:retrieve>. В конце концов, вы запускаете сборку для создания новых jar-файлов, и они должны быть НЕКОТОРЫМИ в вашей сборке. В противном случае, если вы не создаете банку или войну, что вы пытаетесь опубликовать в своем хранилище Ivy? И вы, конечно же, не хотите получать что-то уже в своем репозитории Ivy, чтобы просто переиздать это.

---

Моя философия всегда заключалась в том, что публикация является задачей CM и не должна выполняться в рамках процедуры сборки. Таким образом, мы не используем <ivy:deliver> или <ivy:publish>.

Мы используем Artifactory в качестве нашего хранилища Ivy (и нашего хранилища Maven). Мы используем Jenkins в качестве нашего сервера непрерывной сборки.

Я хочу, чтобы разработчики сделали файл pom.xml из своего файла ivy.xml с помощью задачи <ivy:makepom>. Это и сборочные файлы / войны сохраняются как архивные артефакты в Jenkins.

Когда мы довольны конкретной сборкой и хотим, чтобы она была в нашем общедоступном репозитории, я использую задачу Jenkin Promote Build для продвижения конкретного jar / war с его pom.xml в наш репозиторий Artifactory. Для этого мы используем задачу mvn deploy:deploy-file.

Answer 4

Важно понимать, что Айви делает здесь. Это НЕ просто копирование ваших файлов артефактов в репозиторий ivy - оно также генерирует соответствующие файлы «.ivy.xml», в которых указаны все зависимости каждого из ваших артефактов.

Под прикрытием задача ivy:retrieve фактически также вызывает ivy:resolve. Когда происходит это ivy: resolve, файл записывается в локальный кеш ivy (в папке .ivy в user.home), который указывает, как произошло разрешение (какие ревизии каких модулей потребовалось для завершения разрешения.) 1007 * обнаружено, что запись разрешения извлекается из кэша и используется для создания ivy.xml для ваших артефактов.

Самым большим подводным камнем, с которым я столкнулся при этом, является требование, чтобы задачи ivy:resolve и ivy:publish загружались одним и тем же загрузчиком классов при выполнении ant. Самый простой способ убедиться в этом - использовать loaderRef для задач taskdef. Например (обратите внимание на соответствующие теги loaderRef):

<taskdef name="ivy-retrieve" 
     classname="org.apache.ivy.ant.IvyRetrieve" 
     classpathref="ivy.lib" 
     loaderRef="ivy.loader"/>
<taskdef name="ivy-publish" 
     classname="org.apache.ivy.ant.IvyPublish" 
     classpathref="ivy.lib" 
     loaderRef="ivy.loader"/>