Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
490 views
in Technique[技术] by (71.8m points)

ant - Ivy, what is the master configuration and why is it not pulling jvyaml?

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

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Reply

0 votes
by (71.8m points)

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>

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
OGeek|极客中国-欢迎来到极客的世界,一个免费开放的程序员编程交流平台!开放,进步,分享!让技术改变生活,让极客改变未来! Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

1.4m articles

1.4m replys

5 comments

57.0k users

...