Подтвердить что ты не робот

Как плющ: публиковать работу?

Я полностью потерял, как должно работать ant задача ivy: публикация.

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

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

Update:

<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 баночки, 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:

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

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

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

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

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

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

4b9b3361

Ответ 1

Вам нужно указать "resolver". Что-то вроде:

<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>

Ответ 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>

Элемент информации и элементы публикации в ivy.xml позволяют вам пропустить различные атрибуты элементов плюща в файле 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>

...

Ответ 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, но опубликует ваши банки/войны для правильной ревизии. Я предпочитаю использовать параметр pubrevision задачи <ivy:deliver> и пусть он все равно создаст правильный файл ivy.xml. Затем <ivy:publish> будет использовать ревизию в моем файле ivy.xml.

Вам не нужно делать <ivy:retrieve>. В конце концов, вы запускаете сборку для создания новых банок, и они должны быть SOMEWHERE в вашей сборке. В противном случае, если вы не создаете банку или войну, что пытаетесь опубликовать в своем репозитории Ivy? И, конечно же, вы не хотите получать что-то уже в своем репозитории Ivy, чтобы переиздать его.


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

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

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

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

Ответ 4

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

Под обложками задача ivy:retrieve фактически также запускает ivy:resolve. Когда происходит это решение ivy: файл записывается в ваш локальный кэш плюща (в папке .ivy в user.home), который указывает, как произошло разрешение (какие изменения для модулей потребовались для завершения разрешения). Когда ivy:publish, эта запись разрешения извлекается из кеша и используется для генерации 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"/>