ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: retrieve doesnt
Date Thu, 09 Nov 2006 15:48:37 GMT
Xavier Hanin wrote:
> On 11/9/06, Steve Loughran <> wrote:
>> Xavier Hanin wrote:
>> > It seems that Ivy find the modules but no artifacts (only 0 in the
>> artifact
>> > number column). So either the module descriptors for your dependencies
>> > define no published artifact, or you depend on a configuration in these
>> > module which have no artifacts.
>> >
>> > Could you share your ivy.xml (and maybe also your ivyconf.xml)?
>> I'm pulling in stuff from the m2 repository, at least trying to.
> Ok, so it must be due to a problem of pom conversion or something like 
> that.
> To investigate on that I'd suggest checking directly your ivy cache (should
> be in ~/.ivy/cache) where ivy put the log4j module descriptor for example.
> You will see an ivy file, and also a file called
> This file is interesting because it contains information about which
> resolver was used to get the ivy.xml. Note that even if maven2 
> repository is
> used, you will get an ivy.xml which will be the result of a pom conversion.
> This may help you to know why you have no artifact in your runtime
> configuration of log4j.

OK. now its clear.

the 'runtime' includes dependencies, but not the generated artifact 
itself. if I depend on runtime, I dont get the primary artifact.

<ivy-module version="1.0">
         <info organisation="log4j"
                 <conf name="default" visibility="public" 
description="runtime dependencies and master artifact can be used with 
this conf" extends="runtime,master"/>
                 <conf name="master" visibility="public" 
description="contains only the artifact published by this module itself, 
with no transitive dependencies "/>
                 <conf name="compile" visibility="public" 
description="this is the default scope, used if none is specified. 
Compile dependencies are available in all classpaths."/>
                 <conf name="provided" visibility="public" 
description="this is much like compile, but indicates you expect the JDK 
or a container to provide it.  It is only available on the compilation 
classpath, and is not transitive."/>
                 <conf name="runtime" visibility="public" 
description="this scope  indicates that the dependency is not required 
for compilation, but is for execution. It is in the runtime and test 
classpaths, but not the compile classpath." extends="compile"/>
                 <conf name="test" visibility="private" 
description="this scope indicates that the dependency is not required 
for normal use of the application, and is only available for the test 
compilation and execution phases."/>
                 <conf name="system" visibility="public" 
description="this scope is similar to provided except that you have to 
provide the JAR which contains it  explicitly. The artifact is always 
available and is not looked up in a repository."/>
                 <artifact name="log4j" type="jar" ext="jar" conf="master"/>

> BTW, using in a same environment both maven2 repository and ivyrep can lead
> to tricky problems of names. I usually do not suggest to use both, and
> prefer the use of a maven 1 repository for artifacts only. Note that if you
> really want to use maven 2 repository and their poms alongside ivyrep, you
> caan use the namespace feature to map maven2 namespace to ivyrep one. This
> takes time to setup (you have to write a set of rewriting rules) but can
> solve problem elegantly.

I'm not sure if rewrite rules consitute elegance. Workaround, yes. 
Elegance? doubtful.


View raw message