ivy,主配置是什么,为什么不拉jvyaml? [英] Ivy, what is the master configuration and why is it not pulling jvyaml?

查看:16
本文介绍了ivy,主配置是什么,为什么不拉jvyaml?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有以下常春藤文件:

<conf name="buildtime"visibility="private" description="只需要编译的库"/><conf name="runtime" description="仅在运行时需要库"/><conf name="test" description="仅用于测试的库"/></配置><依赖项><dependency org="net.java.dev" name="jvyaml" rev="0.2.1" conf="runtime"/><dependency org="org.apache.solr" name="solr-core" rev="3.6.0" conf="runtime"/></依赖项>

我有一个蚂蚁检索任务,如下所示:

奇怪的是,所有 solr 依赖项都按照我的预期下载到 lib/runtime 中,但 jvyaml 模块没有!它解决",但不会下载到 lib/runtime 目录,除非我将依赖声明更改为:

这个主配置是什么,为什么需要拉jvyaml jar,而不是solr?

谢谢

解决方案

我建议按如下方式重构您的配置:

<信息组织=com.myspotontheweb"模块=演示"/><配置><conf name="compile" description="仅编译所需的库"/><conf name="runtime" description="仅在运行时需要的库" extends="compile"/><conf name="test" description="仅用于测试的库" extends="runtime"/></配置><依赖项><dependency org="net.java.dev" name="jvyaml" rev="0.2.1" conf="runtime->default"/><dependency org="org.apache.solr" name="solr-core" rev="3.6.0" conf="runtime->default"/></依赖项></ivy-module>

引入的重要变化:

  1. 使用更标准的编译"配置
  2. 配置继承使用扩展"属性.然后,编译依赖项可以自动包含在运行时和测试配置中.
  3. 使用配置映射,例如:conf="runtime->default".这使得哪个本地配置与哪个远程配置相关联变得一目了然.

配置映射说明

配置是一个强大的常春藤功能.当 ivy 下载 Maven 模块时,它会执行内部转换并分配一组标准配置,列在此答案中:

在声明依赖项时,最好始终使用配置映射,以便毫无疑问地将依赖项工件分配到何处.

例如:

默认"/>

这里我们说的是我们希望远程模块的默认依赖项与我们的本地运行时配置相关联.

实际上,您实际上只需要两个远程配置映射:

  • 默认:远程模块的工件及其所有运行时传递依赖
  • ma​​ster:仅远程模块的工件(无传递依赖项)

总而言之,我认为您的问题是由于远程 Maven 模块的运行时"范围不包括 Maven 模块的工件,而是您获得了模块 jvyaml 的不存在的传递依赖项 :-(

一些额外的建议

我还建议生成一份常春藤依赖管理报告,如下所示:

<ivy:resolve/><ivy:report todir="${build.dir}/ivy-report" graph="false"/><ivy:retrieve pattern="lib/[conf]/[artifact]-[revision].[ext]"/></目标>

该报告将帮助解释每个依赖项如何最终依赖于不同的配置.对于确定如何管理传递依赖项也非常有用.

最后,这里是配置继承带来回报的地方,创建常春藤管理的 ANT 类路径:

<ivy:resolve/><ivy:report todir="${build.dir}/ivy-report" graph="false"/><ivy:cachepath pathid="compile.path" conf="compile"/><ivy:cachepath pathid="runtime.path" conf="runtime"/><ivy:cachepath pathid="test.path" conf="test"/></目标>

I have the following ivy file:

<configurations defaultconfmapping="buildtime">
    <conf name="buildtime" visibility="private" description="Libraries needed only for compilation" />
    <conf name="runtime" description="Libraries only needed at runtime" />
    <conf name="test" description="Libraries only needed for testing" />
</configurations>

<dependencies>
  <dependency org="net.java.dev" name="jvyaml" rev="0.2.1" conf="runtime" />
  <dependency org="org.apache.solr" name="solr-core" rev="3.6.0" conf="runtime" />

</dependencies>

and I have an ant retrieve task that looks like this:

<target name="retrieve-all" depends="resolve">
    <ivy:retrieve pattern="lib/[conf]/[artifact]-[revision].[ext]" conf="*" />
</target>

The weird thing is, that all the solr dependencies download into lib/runtime as I'd expect, but the jvyaml module does not! It 'resolves', but will not download into the lib/runtime directory unless I change the dependency declaration to:

<dependency org="net.java.dev" name="jvyaml" rev="0.2.1" conf="runtime->master" />

What is this master configuration and why is it needed to pull the jvyaml jar, but not solr?

Thanks

解决方案

I would suggest restructuring your configurations as follows:

<ivy-module version="2.0">
    <info organisation="com.myspotontheweb" module="demo"/>

    <configurations>
        <conf name="compile" description="Libraries needed only for compilation" />
        <conf name="runtime" description="Libraries only needed at runtime" extends="compile" />
        <conf name="test" description="Libraries only needed for testing" extends="runtime" />
    </configurations>

    <dependencies>
        <dependency org="net.java.dev" name="jvyaml" rev="0.2.1" conf="runtime->default" />
        <dependency org="org.apache.solr" name="solr-core" rev="3.6.0" conf="runtime->default" />
    </dependencies>

</ivy-module>

Important changes introduced:

  1. Use the more standard "compile" configuration
  2. Configuration inheritance using the "extends" attribute. Compile dependencies can then be automatically included in both the runtime and test configurations.
  3. Use configuration mappings, for example: conf="runtime->default". This makes it obvious which local configuration is associated with which remote configuration.

Configuration mappings explained

Configurations are a powerful ivy feature. When ivy downloads Maven modules it performs an internal translation and assigns a standard set of configurations, listed in this answer:

When declaring a dependency it's a good idea to always make use of a configuration mapping, so that there is no doubt where the dependencies artifacts are assigned.

For example:

<dependency org="??" name="??" rev="??" conf="runtime->default" />

Here we're saying we want the remote module's default dependencies associated with our local runtime configuration.

In practice, there are only two remote configuration mappings you'll actually need:

  • default: The remote module's artifact and all it's runtime transitive dependencies
  • master: The remote module's artifact only (No transitive dependencies)

In conclusion, I think your problem was caused by the fact that the remote Maven module's "runtime" scope does not include Maven module's artifact, instead you were getting the non-existant transitive dependencies of the module jvyaml :-(

Some additional advice

I'd also suggest generating an ivy dependency management report, as follows:

<target name="init" description="Resolve dependencies and populate lib dir">
    <ivy:resolve/>
    <ivy:report todir="${build.dir}/ivy-report" graph="false"/>
    <ivy:retrieve pattern="lib/[conf]/[artifact]-[revision].[ext]"/>
</target>

The report will help explain how each dependency ends up on different configurations. Also really useful for determining how transitive dependencies are being managed.

And finally, here's where the configuration inheritance pays off, creating ivy managed ANT classpaths:

<target name="init" description="Resolve dependencies and set classpaths">
    <ivy:resolve/>
    <ivy:report todir="${build.dir}/ivy-report" graph="false"/>

    <ivy:cachepath pathid="compile.path" conf="compile"/>
    <ivy:cachepath pathid="runtime.path" conf="runtime"/>
    <ivy:cachepath pathid="test.path"    conf="test"/>
</target>

这篇关于ivy,主配置是什么,为什么不拉jvyaml?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆