Ivy - вывод результатов решения в файл ivy

Разрешив мой файл ivy.xml, я хочу создать новый файл resolved-ivy.xml, состоящий из всех переходных зависимостей, найденных в разрешении. Возможно ли это сделать?

Это отличается от доставки, которая (я полагаю) записывает только непосредственные зависимости от вашего ivy.xml, а не транзитивные зависимости. Задача Ant deliver имеет атрибут delivertarget, который в документации выглядит как это должно сделать это. На практике он работает только для модулей в одной организации (поэтому обычно не для всех зависимостей) и создает файл для каждого модуля.

Он также отличается от XML-файла ivy-report, который создается во время разрешения, но не сильно отличается. Если то, что я пытаюсь сделать, невозможно, то, я полагаю, я просто взломаю этот файл напрямую.

Контекст здесь пытается обеспечить повторяемость воспроизводимых сборок, в том числе при наличии изменений (новых библиотек, версий) в репозитории. В Интернете есть сообщения, которые пытаются это сделать, и ни один из них, который я нашел, не может сделать это должным образом.

  • Дополнения к репозиторию Ivy могут изменить результаты разрешения, в частности, если какие-либо зависимости в любом месте репозитория (не только ваш проект) имеют зависимости от диапазона. Пример: A зависит от B;[2.0,4.0], а B;3.1 позже добавляется в репозиторий.
  • Идея состоит в том, чтобы разрешить как обычно, записать разрешение в виде сплющенного файла Ivy, сохранить его в системе контроля версий вашего проекта для этого тега (или чего-то еще) и впоследствии разрешить этот файл с помощью transitive="false". Предполагая, что существующие элементы в репозитории не изменяются, это позволяет повторять сборки.
  • Если у кого-то есть лучшие идеи для этого, я все уши. На данный момент я ожидаю, что мне придется взломать некоторую комбинацию ResolveEngine, чтобы сделать ResolveReport доступным, а затем добавить пользовательское DeliverEngine, чтобы использовать его.

person Joe Kearney    schedule 04.05.2012    source источник


Ответы (3)



артефактный отчет> может помочь.

Используйте задачу доставки для создания ivy.xml с динамическими ограничениями версии, замененными статическими ограничениями версии (т.е. [2.0,3.0[ становится 2.2.1):

<ivy:deliver conf="*(public)" deliverpattern="${dist.dir}/ivy.xml"/>

Затем используйте задачу разрешения для этого файла, чтобы подготовить отчет об артефакте.

<ivy:resolve file="${dist.dir}/ivy.xml"
             conf="*(public)"
             refresh="true"
             type="ivy" />

Наконец, ArtifexReport выполнит временное разрешение зависимостей.

<ivy:artifactreport tofile="${dist.dir}/artifactreport.xml" />

Artifertreport.xml будет выглядеть так

<modules>
<module organisation="com.googlecode.flyway" name="flyway" rev="1.7" status="release"/>
<module organisation="org.postgresql" name="postgresql-jdbc" rev="9.0" status="release"/>
<module organisation="org.hibernate" name="hibernate" rev="3.3.2" status="release"/>
<module organisation="org.apache.commons" name="commons-daemon" rev="1.0.2" status="release"/>
...

Используйте XSLT для создания формы ivy.xml.

person Martin    schedule 16.11.2012

В обычных обстоятельствах я бы сказал, что это перебор. Проблема, которую вы пытаетесь решить, заключается в том, что ваш репозиторий ненадежен..... Возможно, вам следует подумать об использовании менеджера репозитория для управления вашим репозиторием?

(Артефакты, опубликованные в Maven Central, преднамеренно никогда не изменялись, это гарантирует, что люди, использующие репозиторий, не столкнутся с нестабильностью сборки).

Сказав все это, если вы не можете полностью доверять конфигурации модуля репозитория, то то, что вы пытаетесь сделать, возможно с помощью ivy отчет об артефакте. Он создает отчет XML, который можно преобразовать с помощью XSLT в новый файл ivy.

Пример

$ tree
.
|-- build.xml
|-- ivy.xml
`-- src
    `-- main
        `-- xsl
            `-- artifactreport.xsl

build.xml

<project name="demo" default="build" xmlns:ivy="antlib:org.apache.ivy.ant">

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

    <target name="build" depends="init">
        <ivy:artifactreport tofile="build/reports/artifacts.xml"/>

        <xslt style="src/main/xsl/artifactreport.xsl" in="build/reports/artifacts.xml" out="build/ivy.xml"/>
    </target>

</project>

артефактрепорт.xsl

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

    <xsl:output method="xml" indent="yes"/>

    <xsl:template match="/">
        <ivy-module version="2.0">
            <info organisation="com.myspotontheweb" module="demo"/>

            <dependencies>
                <xsl:apply-templates select="modules/module"/>
            </dependencies>

        </ivy-module>
    </xsl:template>

    <xsl:template match="module">
        <dependency org="{@organisation}" name="{@name}" rev="{@rev}"/>
    </xsl:template>

</xsl:stylesheet>
person Mark O'Connor    schedule 05.05.2012
comment
Я не говорю об изменении артефактов, которые мы запрещаем именно по этой причине. Я говорю о дополнениях к репозиторию, которые влияют на разрешение версий. Допустим, одна из моих зависимостей зависит от CoolLib [10.0, 12.0), а в репозиторий добавлена ​​отладочная версия 11.1. Я не хочу, чтобы моя сборка (которая может быть выпуском с фиксированными тегами) менялась, когда это происходит, хотя очевидно, что новая версия удовлетворяет моим ограничениям. artifactreport может работать для этого; Я действительно надеялся, что мне не придется копаться в файлах Ivy вручную. - person Joe Kearney; 08.05.2012
comment
Аааа, теперь я понимаю. По этой причине я не использую диапазоны ревизий. Иногда я буду использовать динамические версии, такие как last.release, в сочетании с задачей доставки ivy, чтобы определить фактическую версию опубликованного файла ivy. - person Mark O'Connor; 09.05.2012