[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ivy-user
Subject:    Several newbie questions about configurations
From:       Tom Anderson <twic () urchin ! earth ! li>
Date:       2011-11-13 21:51:18
Message-ID: alpine.DEB.2.00.1111132108520.19917 () urchin ! earth ! li
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]