ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Podkowinski <>
Subject Re: [Ivy IDE] source file resolution fails
Date Tue, 12 Oct 2010 13:38:13 GMT
The ivy.xml I'm using throughout my projects looks more or less like this:

<ivy-module version="2.0">
    <info organisation="${ivy.organisation}" module="${ivy.module}"
		<conf name="default" visibility="public" description="runtime
dependencies and master artifact can be used with this conf"
		<conf name="master" visibility="public" description="contains only
the artifact published by this module itself, with no transitive
		<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." extends="runtime"/>
		<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."/>
		<conf name="sources" visibility="public" description="this
configuration contains the source artifact of this module, if any."/>
		<conf name="javadoc" visibility="public" description="this
configuration contains the javadoc artifact of this module, if any."/>
		<conf name="optional" visibility="public" description="contains all
optional dependencies"/>
    	<artifact name="${ivy.module}" conf="*"/>
		<dependency org="org.springframework"
name="org.springframework.spring-library" rev="3.0.4.RELEASE"/>
		<dependency org=""
name="" rev="3.0.3.RELEASE" />
		<dependency org=""
name="" rev="3.0.3.RELEASE" />
		... [ other dependencies ] ...

		<exclude module=""/>
		<exclude module=""/>
		<exclude module="com.springsource.javax.servlet"/>
		<exclude module=""/>

Placeholders are read from a property file so I only have to change
the dependencies between projects.

On Mon, Oct 11, 2010 at 1:48 PM, David Harrigan <> wrote:
> Hi Sefan
> What does your ivy.xml look like?
> -=david=-
> On 11 October 2010 10:54, Stefan Podkowinski <> wrote:
>> Can someone please advise what to do to make the source resolution
>> feature work in Ivy IDE? For each artrifact ivy will download the
>> appropriate sources to the local cache e.g.:
>> $HOME/.ivy2/cache/org.springframework/org.springframework.core/jars/org.springframework.core-3.0.4.RELEASE.jar
>> $HOME/.ivy2/cache/org.springframework/org.springframework.core/srcs/org.springframework.core-sources-3.0.4.RELEASE.jar
>> However, when I'm trying to open a class from the ivy classpath in
>> Eclipse, the source file cannot be resolved:
>> "Source not found"
>> "The JAR of this class belongs to container 'ivy.xml [*]' which does
>> not allow modifications to source attachments on its entries"
>> I noticed that there are some related options under Ivy > Classpath:
>> Sources types: source
>> Sources suffixes: -source,-sources,-src
>> Using Ivy 2.2.0 (20100923230623) and IvyDE
>> This is really driving me nuts as I have no clues where ivyde is
>> actually looking for the sources. Any ideas?
> --
> I prefer encrypted and signed messages. KeyID: B20A22F9
> Fingerprint: 110A F423 3647 54E2 880F ADAD 1C52 85BF B20A 22F9
> "It is not usually until you've built and used a version of the
> program that you understand the issues well enough to get the design
> right." - Rob Pike, Brian Kernighan.

View raw message