如何避免与Ivy复制依赖关系

Ale*_*den 9 dependencies jar ivy

我正在研究使用常春藤来管理依赖关系,但是哇 - 这件事真的很喜欢制作多个罐子的副本!它像我的后院常春藤一样蔓延,同样不受欢迎!

有没有可能让Ivy简单地定义一个类路径(对于指定的配置文件)引用已解析的依赖项,以便我的javac可以直接在ivy存储库(或缓存?)中引用它们.

我已经阅读了参考文档,只看到设置存储库缓存的符号链接的选项.我想这就足够了,但这似乎是浪费.此外,我不确定"战争"任务是否可以通过符号链接来构建战争......但我想我会在尝试时找到它.

有更好的建议吗?

Mar*_*nor 14

这是我创建可执行文件的标准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>
Run Code Online (Sandbox Code Playgroud)

正如您在常春藤文档中发现的那样,cachepath常春藤任务用于管理两条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>
Run Code Online (Sandbox Code Playgroud)

总之,我希望这个例子有助于理解常春藤.我喜欢它只专注于一件事的方式,即第三方依赖的管理.


Ale*_*den 3

在与写得很糟糕的 Ivy 文档作斗争之后(叹息 - 这些人出了什么问题? - 他们没有参加任何语言的高中识字课程吗?),我看到有一个名为cachepath的解析后任务,它将构建一个 ant已解析依赖项工件的路径,而不是将文件复制到 lib 目录。这可能正是我正在寻找的!

  • 为 ivy 提供解决方案并创建更好的文档不是更好吗?这似乎比整个部门管理系统的维护要少 (11认同)
  • 我放弃!Ivy 文档太糟糕了,它使得整个框架完全毫无用处。我将不得不编写自己的依赖管理构建配置。 (4认同)