Return-Path: 
 <ivy-user-return-8200-apmail-ant-ivy-user-archive=ant.apache.org@ant.apache.org>
X-Original-To: apmail-ant-ivy-user-archive@www.apache.org
Delivered-To: apmail-ant-ivy-user-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id A560B9D4D
	for <apmail-ant-ivy-user-archive@www.apache.org>;
 Tue, 17 Jan 2012 20:23:48 +0000 (UTC)
Received: (qmail 20514 invoked by uid 500); 17 Jan 2012 20:23:48 -0000
Delivered-To: apmail-ant-ivy-user-archive@ant.apache.org
Received: (qmail 20467 invoked by uid 500); 17 Jan 2012 20:23:46 -0000
Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:ivy-user-help@ant.apache.org>
List-Unsubscribe: <mailto:ivy-user-unsubscribe@ant.apache.org>
List-Post: <mailto:ivy-user@ant.apache.org>
List-Id: <ivy-user.ant.apache.org>
Reply-To: ivy-user@ant.apache.org
Delivered-To: mailing list ivy-user@ant.apache.org
Received: (qmail 20459 invoked by uid 99); 17 Jan 2012 20:23:46 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Jan 2012 20:23:46 +0000
X-ASF-Spam-Status: No, hits=1.5 required=5.0
	tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of jimmy@indeed.com designates
 209.85.216.45 as permitted sender)
Received: from [209.85.216.45] (HELO mail-qw0-f45.google.com) (209.85.216.45)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Jan 2012 20:23:41 +0000
Received: by qabg40 with SMTP id g40so1115651qab.4
        for <ivy-user@ant.apache.org>; Tue, 17 Jan 2012 12:23:20 -0800 (PST)
Received: by 10.229.75.147 with SMTP id y19mr7006903qcj.33.1326831799961; Tue,
 17 Jan 2012 12:23:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.231.138 with HTTP; Tue, 17 Jan 2012 12:17:25 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1111132108520.19917@urchin.earth.li>
References: <alpine.DEB.2.00.1111132108520.19917@urchin.earth.li>
From: Jimmy Wan <jimmy@indeed.com>
Date: Tue, 17 Jan 2012 14:17:25 -0600
Message-ID: 
 <CAFaBSyVPS9W=bmUaVOLEjwGDiSc1+3BnA4mb+8i0X9gFD6cEYw@mail.gmail.com>
Subject: Re: Several newbie questions about configurations
To: ivy-user@ant.apache.org
Content-Type: multipart/alternative; boundary=002354333a861d087804b6bf1a91

--002354333a861d087804b6bf1a91
Content-Type: text/plain; charset=ISO-8859-1

Tom, we have always used a separate configuration called "test" to handle
test dependencies and that has always worked well for us. We generally
don't worry about test artifacts that are test dependencies for another
project.

On Sun, Nov 13, 2011 at 15:51, Tom Anderson <twic@urchin.earth.li> wrote:

> Hello!
>
> Zeroth question: is there any good documentation about working with
> configurations and configuration mappings, other than:
>
>
> http://ant.apache.org/ivy/history/latest-milestone/ivyfile/configurations.html
> http://ant.apache.org/ivy/history/latest-milestone/ivyfile/dependency.html
>
> ? I've read those, but there's still plenty to know.
>
> First question: is there any kind of standard or best practice for what
> configurations a module should define? I can see that everything imported
> from the Maven repositories has a standard set; should i be following that
> pattern, ignoring it, or doing something else? That question is partly
> about knowing what configurations my own modules should define, but also
> about what i should expect from other modules; if there is no standard,
> does that mean i will end up tailoring configuration mappings for every
> dependency?
>
> For now, i am using a cut-down version of the Maven configurations:
>
> <conf name="compile"/> <!-- things needed to compile the code -->
> <conf name="master"/> <!-- things published by this module -->
> <conf name="runtime" extends="compile"/> <!-- things needed to run the
> code -->
> <conf name="default" extends="runtime,master"/> <!-- everything, needed or
> provided, necessary to use this module -->
> <conf name="sources"/> <!-- sources for this module and dependencies -->
>
> Second question: is this sane?
>
> Third question: how do i deal with dependencies needed by unit tests, but
> not the module's artefact? I am writing a module that uses JUnit and Moxie
> for testing, so i have those as compile dependencies. But anyone who wanted
> to obtain and use the module would not need them; they wouldn't even need
> them to build from source, as long as they didn't want to run the tests.
> Should i just define a separate test configuration? Any suggestions on how
> that should relate to the others?
>
> Third question: i currently have the following default configuration
> mapping:
>
> <dependencies
> defaultconfmapping="compile->compile;runtime->default;sources->sources">
>
> My goal here is that if i retrieve the compile configuration, i will get
> just the things i need to compile my code (ie not transitive dependencies),
> if i retrieve the runtime configuration, i will get everything i need to
> actually run the code, and if i retrieve the sources configuration, i will
> get the source code of all my dependencies (so i can link it into my IDE).
> Am i doing this right? Do i need to specify these explicitly, or should i
> be relying on defaults? Is it really right that i have to specify
> runtime->default in order to get modules and their transitive dependencies?
> Would i be better off specifying runtime->master,runtime explicitly? Can i
> rely on any of these configurations existing across all modules?
>
> Fourth question: what is the preferred style for writing a dependency that
> means something like "the latest released version"? So far, i've been
> writing:
>
> <dependency org="junit" name="junit" rev="4.+"/>
>
> I think i actually need JUnit 4.6 or later. Since i know that has been
> released, can i safely write 4.+? Should i explicitly say [4.6,)? Any
> thoughts on whether it's best to exclude, explicitly or implicitly, version
> 5 and beyond, on the grounds that it might not be backward compatible?
> Should i just say latest.release?
>
> Fourth question: any idea what's going on with Moxie and cglib? For those
> of you who don't know them, Moxie is a mocking library (like Mockito or
> JMock - some would say better) and cglib is a bytecode generation library.
> Moxie uses cglib; if you ask it to mock a class (rather than an interface),
> it uses a couple of classes from cglib. That means it has a compile-time
> dependency on cglib, and if you want to mock classes, a runtime dependency.
> Its ivy.xml says this about configurations (this is just the ones which
> look relevant):
>
>  <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="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="optional" visibility="public" description="contains all
> optional dependencies"/>
>
> And this about dependencies:
>
> <dependencies>
>  <dependency org="junit" name="junit" rev="4.8.1" force="true"
> conf="optional->compile(*),master(*)"/>
>  <dependency org="org.hamcrest" name="hamcrest-core" rev="1.1"
> force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
>  <dependency org="org.hamcrest" name="hamcrest-library" rev="1.1"
> force="true" conf="optional->compile(*),master(*)"/>
>  <dependency org="cglib" name="cglib" rev="2.1_3" force="true"
> conf="optional->compile(*),master(*)"/>
> </dependencies>
>
> Am i right in reading that as saying that the only dependency brought in
> in the compile configuration, and therefore also by the runtime and default
> configurations, is hamcrest-core? And that the other three are only brought
> in by the optional configuration? Does that seem correct?
>
> It does seem to be the case, because i had to write this dependency:
>
> <dependency org="org.moxiemocks" name="moxie" rev="0.+"
> conf="compile->compile;runtime->default,optional;sources->sources"/>
>
> In order to bring in cglib when i did a retrieve of the runtime
> configuration. On which subject ...
>
> Fifth question: when i write a dependency-level configuration mapping, it
> seems to completely override the default configuration mapping. If i take
> away the sources->sources entry in the above, then when i retrieve the
> sources configuration, i don't get the sources for Moxie. Is there any way
> to write a dependency-level configuration mapping that lets the mappings
> defined in the default mapping apply except where overridden?
>
> In general, it strikes me that i am writing too many thing explicitly. Are
> there more defaults i should be relying on here?
>
> Thanks for reading all that, and thanks in advance for any advice you may
> be able to give!
>
> tom
>
> --
> That's the problem with google. You can usually find what you're looking
> for with a fairly simple search. It's knowing *which* fairly simple
> search out of the millions of possible fairly simple searches you need
> to use to find it ;-) -- Paul D
>

--002354333a861d087804b6bf1a91--