ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Multiple classpaths
Date Wed, 27 Apr 2011 23:05:02 GMT
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"/>
      <conf name="production"/>
      <dependency org="org.springframework" name="org.springframework.beans"        rev="3.0.5.RELEASE"
      <dependency org="org.springframework" name="org.springframework.web.servlet"  rev="3.0.5.RELEASE"
      <dependency org="junit" name="junit"  rev="4.8.2" conf="production"/>
--- 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;working@dcorbin-mackbook-pro.local 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;working@dcorbin-mackbook-pro.local 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;working@dcorbin-mackbook-pro.local production
[ivy:cachepath] 		::::::::::::::::::::::::::::::::::::::::::::::

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 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
> ________________________________________
> From: Tim Brown []
> Sent: Monday, April 25, 2011 10:30 PM
> To:
> 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 <> 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

View raw message