Think of it this way:
Rule #1: A configuration is just a name for some subset of a module's
artifacts.
Rule #2: A dependency defind in module A's ivy.xml that looks like:
<dependency name="B" conf="foo->bar"/>
simply states that "when someone is asking for the artifacts in
configuration 'foo' of module A, then we'll also need the artifacts in
configuration 'bar' of module B".
Hope that helps.
-Archie
On Wed, Apr 22, 2009 at 12:10 PM, Tom <t...@tbee.org> wrote:
>
> In this case, you're relying on Ivy's default configuration mapping, which
>> I believe is "*->*", which means you'll get all of the artifacts (jars)
>> defined by *any* of the dependency's configurations.
>>
>
> Ok. I do not understand what that means, but ok.
>
>
> Now you have limited the artifacts to those defined by the "default"
>> configuration of each dependency. That probably doesn't include jars from
>> configs like "test", "sources", etc.
>>
>
> I have tried "runtime->*" but that did not change anything.
>
>
>
> Configuration mapping has been the most confusing part of Ivy for me. I
>> still haven't mastered the use of it to come up with a best practices within
>> our organization.
>>
>
> May I put on the table that if a feature is this complicated to use, that
> maybe there is a flaw in the underlying concept? I still do not understand
> what configurations are trying to do. Are they:
> - trying to bind dependencies to usages? (The dependency is used within the
> scope "test", or "runtime", as I'm trying to do now)
> - trying to bind dependencies to deliverables? (For the deliverable
> "xyz.jar", use dependencies...)
>
> I also did not find a concept of "configuration" in Maven. Let's look at
> this from a simplistic approach:
> 1. my four dependency lines are resolved by Ivy to a list of 93 jars.
> 2. the only thing I can do with this list is limited / filter, I cannot
> expand it any further
> 3. so appearantly the configuration allows applying a filter to this list
> 4. you must filter on some attribute that is assigned to each jar... where
> would that assignment take place?
> 5. the jar itself could have that attribute set, but the developer can't
> know for what the jar is used.
> 6. the only logical place to assign a value would be in de ivy.xml in the
> project using it, inheriting from the initial line
>
> Where am I going wrong?
>
>
>
>
>
--
Archie L. Cobbs
