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 [mailto:[email protected]] On Behalf Of Tom Widmer Sent: 10 August 2009 14:31 To: [email protected] 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 directories > that I then reference in my Ant build scripts, such as libraries used at > 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="http://ant.apache.org/ivy/maven";> > <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" rev="1.1"/> To be explicit about it (which is a good idea), I'd have: <dependency org="commons-logging" name="commons-logging" rev="1.1" conf="default->default"/> 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. http://repo1.maven.org/maven2/ http://ivyroundup.googlecode.com/svn/trunk/repo/modules.xml > 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 level. 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). Tom This email has been scanned for all viruses by the MessageLabs SkyScan service. 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 reserved. 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 recipients 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.
