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
