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}"
revision="${ivy.new.revision}"/>
<configurations>
<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." 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"/>
</configurations>
<publications>
<artifact name="${ivy.module}" conf="*"/>
</publications>
<dependencies>
<dependency org="org.springframework"
name="org.springframework.spring-library" rev="3.0.4.RELEASE"/>
<dependency org="org.springframework.security"
name="org.springframework.security.core" rev="3.0.3.RELEASE" />
<dependency org="org.springframework.security"
name="org.springframework.security.config" rev="3.0.3.RELEASE" />
... [ other dependencies ] ...
<exclude module="org.springframework.security"/>
<exclude module="com.springsource.oracle.jdbc"/>
<exclude module="com.springsource.javax.servlet"/>
<exclude module="com.springsource.com.google.common.collect"/>
</dependencies>
</ivy-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 <dharri...@gmail.com> wrote:
> Hi Sefan
>
> What does your ivy.xml look like?
>
> -=david=-
>
> On 11 October 2010 10:54, Stefan Podkowinski <spo...@gmail.com> 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 2.1.0.201008101807.
>>
>> 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.
>
