Как использовать ivy для создания войны без копирования jar-файлов в каталог lib - PullRequest
Новая
       11

Как использовать ivy для создания войны без копирования jar-файлов в каталог lib

6 голосов
/ 16 января 2010

Моя цель - сделать так, чтобы мой сценарий сборки муравья создал файл войны и включал в себя jar-файлы, от которых Айви знает, от чего зависит этот проект. Лучший код, который я мог бы придумать на данный момент, это следующий 

<mkdir dir="dist/lib"/>
<ivy:retrieve pattern="dist/lib/[artifact].[ext]" sync="true"/>
<war destfile="dist/${ivy.module}.war" basedir="build" includes="**/*.class"
    webxml="${war.webxml}">
    <fileset dir="${war.web}"/>
    <lib dir="dist/lib"/>
</war>

Проблема с этим кодом состоит в том, что он копирует банки дважды. Один раз в мой каталог dist / lib и снова на войну, когда он будет создан. Это работает, но я не могу избавиться от ощущения, что есть лучший способ.

Я хотел бы сделать что-то похожее на следующее 

<ivy:cachepath pathid="locpathref.classpath"/>
<war destfile="dist/${ivy.module}.war" basedir="build" includes="**/*.class"
    webxml="${war.webxml}">
    <fileset dir="${war.web}"/>
    <lib refid="locpathref.classpath"/>
</war>

Проблема в том, что тег lib не принимает refid любого вида. Любые идеи или я застрял с дополнительным набором копий файлов?

Ответы [ 2 ]

4 голосов
/ 12 марта 2011

Если вы используете Ant 1.8, вы можете использовать методику, описанную здесь: http://www.beilers.com/2010/06/ivy-dependency-management-lessons-learned-and-ant-1-8-mapped-resources/

Пример: 

<war destfile="${war.full.path}" webxml="WebContent/WEB-INF/web.xml" manifest="${manifest.path}">
    <fileset dir="WebContent">
     </fileset>
    <classes dir="${build.dir}"/>

    <mappedresources>
      <restrict>
        <path refid="classpath.CORE"/>
        <type type="file"/>
      </restrict>
      <chainedmapper>
        <flattenmapper/>
        <globmapper from="*" to="WEB-INF/lib/*"/>
      </chainedmapper>
    </mappedresources>

    <zipfileset dir="src" prefix="WEB-INF/classes">
         <include name="**/resources/**/*.properties" />
         <include name="**/resources/**/*.xml" />
    </zipfileset>
</war>
4 голосов
/ 23 января 2010

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

Если вы хотите улучшить способ, которым ivy управляет зависимостями вашей войны, я мог бы предложить использовать конфигурации?

Создать конфигурацию, описывающую зависимости времени выполнения: 

    <ivy-module version="2.0">
    <info organisation="apache" module="hello-ivy"/>
    <configurations>
        <conf name="build" description="Libraries needed to for compilation"/>
        <conf name="war" extends="build" description="Libraries that should be included in the war file" />
    </configurations>
    <dependencies>
        <dependency org="commons-lang" name="commons-lang" rev="2.0" conf="build->*,!sources,!javadoc"/>
        <dependency org="commons-cli" name="commons-cli" rev="1.0" conf="build->*,!sources,!javadoc"/>
    </dependencies>
</ivy-module>

После этого вы извлекаете их в специальный каталог (используя шаблон), который можно просто включить с помощью тега war задачи lib : 

    <ivy:retrieve pattern="${lib.dir}/[conf]/[artifact].[ext]"/>

    <war destfile="${war.file}" webxml="${resources.dir}/web.xml">
        <fileset dir="${resources.dir}" excludes="web.xml"/>
        <lib dir="${lib.dir}/war"/>
    </war>

Преимущество этого подхода заключается в том, что вы используете атрибут ivy conf каждой зависимости проекта, чтобы в конечном итоге решить, будет ли файл jar включен в файл war или нет. Файл сборки больше не заботится.

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

...