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

Question

Я полностью в убытке, как работает муравей плющ: публикация должна работать.

Я бы ожидал, что я сделаю свою обычную сборку, которая создает кучу файлов 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).

Update 1:

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

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

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

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

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

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

Answer 1

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

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

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

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

Самая большая погрешность, которую я обнаружил при этом, - это требование, чтобы задачи ivy:resolve и ivy:publish были загружены одним и тем же загрузчиком классов, когда они выполняются муравьем. Самый простой способ убедиться в этом - использовать 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"/> 

Answer 3

Сначала вам нужен файл 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> 

... 

Answer 4

Вы, предполагают, чтобы запустить <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.