ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nappin, Chris (IT Services)" <>
Subject RE: Re: Shared repository and configurations question
Date Mon, 10 Aug 2009 14:01:07 GMT
Hi Tom,

  Thanks for confirming I don't need a <configurations> element. 

I've now cracked the problem, I needed to declare each project-specific
configuration inherits from "default" (i.e. conf="confA->default") in
each project's ivy.xml, then I don't need any project-specifics
polluting my repository.

Best Regards,

Chris Nappin 
Technical Architect, Application Services
Mob:	07824 473044

-----Original Message-----
From: news [] On Behalf Of Tom Widmer
Sent: 10 August 2009 14:31
Subject: Re: Shared repository and configurations question

Nappin, Chris (IT Services) wrote:
> Hi Tom and Paul,
>   I'm using ivy configurations to populate various different
> that I then reference in my Ant build scripts, such as libraries used
> compilation time, runtime and executing junit tests. Is that right?

That's generally how they are used, yes. I have:
default, master, runtime, test, ide, ide_javadoc, build, jre and javadoc

> When I create a module dependency file,

module descriptor file I think you mean.

  I've found I have to include
> these project configurations in the file in order for ivy to work.

You don't need a <configurations> element. If you leave out the element,

you by default get a single configuration called 'default'.

  If I
> just have a file as follows, ivy fails with unresolved dependencies:
> <?xml version="1.0" encoding="UTF-8"?>
> <ivy-module version="1.0" xmlns:m="">
> 	<info organisation="abc" module="my-library" revision="2.0.7"/>
> 	<publications>
>           <artifact name="my-library" type="jar" ext="jar"/>
> 	</publications>
> 	<dependencies>
> 		<dependency org="jakarta-commons" name="commons-logging"
> rev="1.1"/>

The ibiblio version would be:
	<dependency org="commons-logging" name="commons-logging"

To be explicit about it (which is a good idea), I'd have:
	<dependency org="commons-logging" name="commons-logging"

That says the implicit default conf of your module depends on the 
default configuration obtained from the POM of commons-logging (which 
won't include sources or docs).

> 	</dependencies>
> </ivy-module>

That looks fine to me - what error are you getting? What does your 
version that uses configurations look like? What errors are you getting 
with that? What resolvers are you using?

> However for my transient dependencies I can not include any module
> dependency file as there is no issue.

Not sure I understand, but lots of 3rd party ivy.xml and .pom files 
(which ivy supports) are available online. e.g.

> An include file would mean I would only have to define these project
> configurations once, but ideally I don't want to define them at all in
> my shared repository?

Configurations aren't properties of a repository. Configurations only 
relate to individual modules - every module in a repository can have 
completely different configurations. e.g.
Module 1: foo bar baz
Module 2: goo gar gaz

You only ever define configurations in individual module descriptors (or

a file to be included in module descriptors), never at the repository

I've very unclear about what your underlying problem is - you don't make

it clear whether you do or don't want to use configurations (e.g. build,

test, runtime, master, default), nor why you think you need to define 
them in your repository (you don't as such).


This email has been scanned for all viruses by the MessageLabs SkyScan

This email and any attachment are intended solely for the addressee, are strictly confidential
and may be legally privileged. If you are not the intended recipient any reading, dissemination,
copying or any other use or reliance is prohibited. If you have received this email in error
please notify the sender immediately by email and then permanently delete the email. Copyright

All communications, incoming and outgoing, may be recorded and are monitored for legitimate
business purposes. 

The security and reliability of email transmission cannot be guaranteed. It is the recipientís
responsibility to scan this e-mail and any attachment for the presence of viruses. 

The Capita Group plc and its subsidiaries ("Capita") exclude all liability for any loss or
damage whatsoever arising or resulting from the receipt, use or transmission of this email.

Any views or opinions expressed in this email are those of the author only.

View raw message