Как избежать копирования зависимостей с помощью плюща

Question

Я изучаю использование Ivy для управления зависимостями, но ничего себе - эта штука действительно любит делать несколько копий банок! Это распространяется как плющ на моем заднем дворе и столь же нежелательно!

Возможно ли, чтобы Ivy просто определил classpath (для указанного профиля), который ссылается на разрешенные зависимости, чтобы мой javac мог ссылаться на них непосредственно в репозитории ivy (или в кеше?).

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

Есть предложения получше?

Answer 1

Вот мой стандартный файл сборки Java, который создает исполняемый файл jar.

Цель состоит в том, чтобы управлять специфическими для проекта материалами с помощью комбинации свойств ANT и файла ivy.xml для сторонних зависимостей.

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

  <property name="src.dir" location="src"/>
  <property name="build.dir" location="build"/>
  <property name="dist.dir" location="dist"/>
  <property name="dist.jar" location="${dist.dir}/${ant.project.name}.jar"/>
  <property name="dist.main.class" value="HelloWorld"/>

  <target name="retrieve">
    <ivy:resolve/>
    <ivy:cachepath pathid="build.path" conf="build"/>
    <ivy:cachepath pathid="runtime.path" conf="runtime"/>
  </target>

  <target name="compile" depends="retrieve">
    <mkdir dir="${build.dir}/classes"/>
    <javac srcdir="${src.dir}" destdir="${build.dir}/classes" classpathref="build.path"/>
  </target>

  <target name="build" depends="compile">
    <ivy:retrieve pattern="${dist.dir}/lib/[artifact].[ext]"/>

    <manifestclasspath property="jar.classpath" jarfile="${dist.jar}">
      <classpath>
        <fileset dir="${dist.dir}/lib" includes="*.jar"/>
      </classpath>
    </manifestclasspath>

    <jar destfile="${dist.jar}" basedir="${build.dir}/classes">
      <manifest>
        <attribute name="Main-Class" value="${dist.main.class}"/>
        <attribute name="Class-Path" value="${jar.classpath}"/>
      </manifest>
    </jar>
  </target>

  <target name="clean">
    <delete dir="${build.dir}"/>
    <delete dir="${dist.dir}"/>
  </target>

</project>

Как вы обнаружили в документе Ivy, задача cachepath Ivy используется для управления двумя путями ANT. Один для зависимостей сборки, другой для зависимостей во время выполнения исполняемого файла jar.

Настоящая сила Плюща в чем-то, что называется configurations. Сначала мне было трудно понять, пока я не понял, что это простая логическая группа из jar, которую я могу определить для своего проекта. Этот пример имеет два configurations:

• build
• runtime

Вот файл ivy, демонстрирующий, как зависимости могут быть связаны с configurations:

<ivy-module version="2.0">
    <info organisation="com.myspotontheweb" module="demo"/>
    <configurations>
        <conf name="build" description="Libraries needed to for compilation"/>
        <conf name="runtime" extends="build" description="Libraries that need to be included with project jar" />
    </configurations>
    <dependencies>
        <dependency org="commons-lang" name="commons-lang" rev="2.0" conf="build->default"/>
        <dependency org="commons-cli" name="commons-cli" rev="1.0" conf="runtime->default"/>
    </dependencies>
</ivy-module>

В заключение, я надеюсь, что этот пример поможет понять Айви. Мне нравится, как он концентрируется только на одном - управлении сторонними зависимостями.

Answer 2

Просто чтобы увеличить @ ответ Марка.

Обратите внимание, что cachepath результат также может быть непосредственно использован в сборке без необходимости копировать jar с retrieve:

<target name="build" depends="compile">
    <jar destfile="${dist.ear}">
        <mappedresources>
            <resources refid="runtime.path"/>
            <chainedmapper>
                <flattenmapper/>
                <globmapper from="*" to="lib/*"/>
            </chainedmapper>
        </mappedresources>
    </jar>
</target>

Answer 3

После борьбы с плохо написанной документацией Айви (вздох - что не так с этими людьми? - они не посещали классы грамотности в старших классах на каком-либо языке?), Я вижу, что есть задание после разрешения, называемое cachepath , который создаст муравейный путь к разрешенным артефактам зависимости вместо копирования файлов в каталог lib. Это может быть именно то, что я ищу!