Several newbie questions about configurations

[Tom Anderson <tw...@urchin.earth.li>]

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

Re: Several newbie questions about configurations

[Jimmy Wan <ji...@indeed.com>]

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 <tw...@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
>