Управление зависимостями плюща для устаревшего хранилища

Question

У нас есть репозиторий, в котором нет ivy.xml и других файлов метаданных. С тех пор он опубликован другой командой, которая не использует ivy/maven, но будет продолжать доставлять код часто.

Банки, необходимые для зависимости, хранятся в плоской структуре внутри одного каталога без данных ревизии. Структура организации / модуля / ревизии отсутствует.

Разрешает ли ivy такие разрешения зависимостей в основном продукте, или мне придется написать собственный распознаватель?

Спасибо

Answer 1

Понимание структуры плюща помогло мне решить проблему. Подвох никогда не указывает шаблон плюща, если в репозитории нет файлов плюща.

Answer 2

Стандартные средства распознавания должны иметь возможность распознавать артефакты ( URL, файловая система и т. Д.). Проблема, с которой вы столкнетесь, заключается в том, что по умолчанию ivy предполагает, что ревизия никогда не меняется. Без информации о версии вам придется настроить стандартные параметры распознавателя, чтобы ivy всегда проверял артефакт.

Страница концепций плюща объясняет, как это работает:

Некоторые люди, особенно выходцы из maven 2 land, любят использовать одну специальную ревизию для обработки часто обновляемых модулей. В Maven 2 это называется версией SNAPSHOT, и некоторые утверждают, что это помогает сэкономить дисковое пространство, чтобы сохранить только одну версию для большого числа промежуточных сборок, которые вы можете сделать во время разработки.

Айви поддерживает такой подход с понятием "изменение редакции". Изменяющаяся ревизия - это просто ревизия, для которой Айви должна учитывать, что артефакты могут со временем меняться. Чтобы справиться с этим, вы можете либо указать зависимость как изменяющуюся в теге зависимости, либо использовать атрибуты changePattern и changeMatcher в своих средствах разрешения, чтобы указать, какая ревизия или группа ревизий должна рассматриваться как изменяющаяся.

Лично мне не нравится этот вид управления зависимостями. Ваша сборка - это движущаяся цель, и ее трудно поддерживать стабильной.

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

Обновить

Ниже приведен пример проекта. Он использует Maven Central и локальный репозиторий для загрузки своих зависимостей.

├── build
│   ├── compile
│   │   ├── artifact1.jar   <-- Changing artifact
│   │   └── slf4j-api.jar
│   ├── runtime
│   │   ├── artifact1.jar   <-- Changing artifact
│   │   ├── artifact2.jar   <-- Changing artifact
│   │   ├── log4j.jar
│   │   ├── slf4j-api.jar
│   │   └── slf4j-log4j12.jar
│   └── test
│       ├── artifact1.jar   <-- Changing artifact
│       ├── artifact2.jar   <-- Changing artifact
│       ├── artifact3.jar   <-- Changing artifact
│       ├── hamcrest-core.jar
│       ├── junit.jar
│       ├── log4j.jar
│       ├── slf4j-api.jar
│       └── slf4j-log4j12.jar
├── build.xml
├── ivysettings.xml
└── ivy.xml

Локальный репозиторий не имеет версий и не имеет файлов плюща. Обычно для распознавателей плюща требуются файлы плюща (или POM в случае Maven), чтобы определить, изменился ли удаленный модуль. При отсутствии метаданных вы можете пометить зависимость как изменяющуюся в файле ivy.

build.xml

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

   <target name="build" description="do something">
     <ivy:retrieve pattern="build/[conf]/[artifact].[ext]"/>
   </target>

   <target name="clean" description="Cleanup build files">
      <delete dir="build"/>
   </target>

   <target name="clean-all" depends="clean" description="Additionally purge ivy cache">
      <ivy:cleancache/>
   </target>

</project>

Заметки:

• Стенд сборки файла с использованием плюща. Задача получения объединяет файлы в различные группы конфигурации.

ivy.xml

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

    <configurations>
        <conf name="compile" description="Required to compile application"/>
        <conf name="runtime" description="Additional run-time dependencies" extends="compile"/>
        <conf name="test"    description="Required for test only" extends="runtime"/>
    </configurations>

    <dependencies>
        <!-- compile dependencies -->
        <dependency org="org.slf4j" name="slf4j-api" rev="1.7.5" conf="compile->default"/>
        <dependency org="myorg" name="artifact1" rev="NA" conf="compile->default" changing="true"/>

        <!-- runtime dependencies -->
        <dependency org="org.slf4j" name="slf4j-log4j12" rev="1.7.5" conf="runtime->default"/>
        <dependency org="myorg" name="artifact2" rev="NA" conf="runtime->default" changing="true"/>

        <!-- test dependencies -->
        <dependency org="junit" name="junit" rev="4.11" conf="test->default"/>
        <dependency org="myorg" name="artifact3" rev="NA" conf="test->default" changing="true"/>
    </dependencies>

</ivy-module>

Заметки:

• У зависимостей "myorg" в качестве ревизии есть фиктивная запись "NA", и они помечены как "изменяющиеся".

ivysettings.xml

<ivysettings>
   <settings defaultResolver="central" />
   <resolvers>
      <ibiblio name="central" m2compatible="true"/>
      <url name="myorg-repo">
         <artifact pattern="http://localhost:8080/userContent/[artifact].[ext]"/>
      </url>
   </resolvers>
   <modules>
      <module organisation="myorg" resolver="myorg-repo"/>
   </modules>
</ivysettings>

Заметки:

• Преобразователь "myorg-repo" настроен для загрузки только зависимостей "myorg". Это позволяет Maven Central разрешать все другие зависимости.
• Средство распознавания "myorg-repo" просто объявляет образец артефакта, я предполагаю, что нет никаких файлов плюща для извлечения.