By default, each configuration is mapped to a configuration of the same name in
the dependency. So in your case, lacking a mapping in the conf attribute or a
defaultconfmapping, you get conf="production->production", that is "my config
production depends on the production config of org.springframework.beans".
You have two choices to resolve this. If all of your configurations and
dependencies use default configs, you could add:
<dependencies defaultconfmapping="*->default">
Or, for each dependency, you can pick the dependent configuration you want for
each of your configs:
<dependency org="com.google" name="gwt" rev="2.2.0"
conf="production->runtime;build->compile"/>
If you choose to use defaultconfmapping, you can still override it on a
per-dependency basis, if you need to (and you will).
Thanks,
---
Kirby Files
Software Architect
Masergy Communications
[email protected]
________________________________________
From: DAVID CORBIN [[email protected]]
Sent: Wednesday, April 27, 2011 7:05 PM
To: [email protected]
Subject: Re: Multiple classpaths
Clearly there's something I'm not grokking. Here's my ivy.xml file.
--- begin ---
<?xml version="1.0"?>
<ivy-module version="2.2">
<info organisation="com.dcorbin" module="foo"/>
<configurations>
<conf name="production"/>
</configurations>
<dependencies>
<dependency org="org.springframework" name="org.springframework.beans"
rev="3.0.5.RELEASE" conf="production"/>
<dependency org="org.springframework"
name="org.springframework.web.servlet" rev="3.0.5.RELEASE" conf="production"/>
<dependency org="junit" name="junit" rev="4.8.2" conf="production"/>
</dependencies>
</ivy-module>
--- end ---
It doesn't work, failing with
[ivy:cachepath] :: problems summary ::
[ivy:cachepath] :::: WARNINGS
[ivy:cachepath] ::::::::::::::::::::::::::::::::::::::::::::::
[ivy:cachepath] :: UNRESOLVED DEPENDENCIES ::
[ivy:cachepath] ::::::::::::::::::::::::::::::::::::::::::::::
[ivy:cachepath] ::
org.springframework#org.springframework.beans;3.0.5.RELEASE: configuration not
found in org.springframework#org.springframework.beans;3.0.5.RELEASE:
'production'. It was required from
com.dcorbin#TichuServer;[email protected] production
[ivy:cachepath] ::
org.springframework#org.springframework.web.servlet;3.0.5.RELEASE:
configuration not found in
org.springframework#org.springframework.web.servlet;3.0.5.RELEASE:
'production'. It was required from
com.dcorbin#TichuServer;[email protected] production
[ivy:cachepath] :: junit#junit;4.8.2: configuration not found
in junit#junit;4.8.2: 'production'. It was required from
com.dcorbin#TichuServer;[email protected] production
[ivy:cachepath] ::::::::::::::::::::::::::::::::::::::::::::::
[ivy:cachepath]
[ivy:cachepath] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
On Apr 26, 2011, at 12:42 AM, Kirby Files wrote:
> To elaborate on that a little:
>
> <configuration> defines a configuration, which may only be used by IvyDE to
> choose a set of deps, or it may be used by your ant scripts to choose a set
> of deps to retrieve -- or you can define which artifacts your <publication>
> will publish for a given configuration. You can use the "standard" set of
> configurations used when Ivy maps poms from Maven (runtime, master, default,
> etc), or define your own for buiilding, testing and deploying.
>
> Your <configurations> element can define a defaultconfmapping. This is useful
> to establish a baseline for mapping dependent configurations (both the
> standards from Maven, and your own) to your configurations:
> defaultconfmapping="build->*;deploy->runtime",
>
> or if you are consistent in all of your configuration naming, and don't use
> anything from Maven, maybe:
> defaultconfmapping="build->*;%->@"
>
> See
> http://ant.apache.org/ivy/history/latest-milestone/ivyfile/dependency.html
> for more on mapping configurations, and how to interpret all the special
> symbols.
>
> Then go through each of your dependencies; some will only be needed when
> compiling, some when you run tests, and some when you deploy (and you may
> have different confs for publications). You can either add a
> conf="build"
> attribute to accept the default conf mapping and only retrieve this dep when
> building; or add
> conf="build->core-apis;deploy->core-runtime"
> for any dependencies which require special attention due to their defining a
> number of extra non-standard configurations.
>
> You may also want transitive="false" on any deps which come from Maven, and
> are known to have bad poms.
>
> Thanks,
> ---
> Kirby Files
> Software Architect
> Masergy Communications
> [email protected]
> ________________________________________
> From: Tim Brown [[email protected]]
> Sent: Monday, April 25, 2011 10:30 PM
> To: [email protected]
> Subject: Re: Multiple classpaths
>
> That's exactly how we use configurations.
>
> The dependency declaration defines the consuming module's config in
> which It needs the dependency.
>
> You can use conf mappings to handle variances of confs across modules,
> including those which don't have confs
>
>
>
> On Apr 25, 2011, at 4:33 PM, David Corbin <[email protected]> wrote:
>
>> I want to produce two classpaths. One for production and one for
>> testing. It kind of looks like configurations might work, but I'm
>> not 100% certain. Is this an appropriate use for configuration?
>> How do I indicate in the dependency that it is part of a given
>> configuration? The conf parameter seems to refer to configurations
>> offered by the dependency itself
>>
>> Thanks
>> David Corbin
