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?
