ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kirby Files <kfi...@masergy.com>
Subject Re: Configurations and Ivy file confusion
Date Wed, 22 Apr 2009 18:10:08 GMT
Tom wrote on 04/22/2009 01:10 PM:
>
>> 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.

A module defines one or more configurations, which will be used to 
meet different needs. For example, the logging framework slf4j defines 
a "core" configuration, which includes only the API jar. It then has a 
configs for each implementation choice a user might want, "log4j", 
"jul", "jcl", etc.

[See the ivy.xml for slf4j in the IvyRoundup repository at:
 
http://ivyroundup.googlecode.com/svn/trunk/repo/modules/org.slf4j/slf4j/1.5.6/ivy.xml
]

If you wanted to use slf4j and log4j in your runtime deployment, you'd 
map your runtime configuration to slf4j's core and log4j configurations:

<dependency name="slf4j" conf="runtime->core,log4j"/>

>> 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.

Curious. Have you tried identifying the set of jars which differs 
between your two ivy.xml files, and looking in your resolution output 
to see which dependencies they derive from?

>> 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?

Well, by default, you can avoid using them, and accept the de facto 
behavior. However, dependency mgmt is a complex practice, and many 
users have differing needs. I myself find the configuration mapping 
helpful, though I use it only lightly. Others with more complex 
environments will find them indispensible. I'm sure others wish Ivy 
had *even more* choice and configurability in this area.

> 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

I would agree so far.

> 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.

In practice, yes, the developer of a library or framework module 
determines what common uses, or profiles, their project has, and 
assigns the jar artifacts to one of these profiles (called 
configurations in Ivy). I don't know a whole lot about Maven, but 
don't think it is anywhere near as flexible as Ivy in this regard, so 
Ivy attempts to helpfully assign Maven scopes to Ivy configurations.

> 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

The goal of configurations is to avoid having to find *all* of the 
jars published by a project, and then explicitly "exlcude" and 
"include" those that you need for say, compilation, deployment, or 
interaction with another framework. Having to use explicit exclusion 
rules for each dependency (which sounds like what you're discussing) 
would be beyond tedious. Configurations allow a module to publish 
different sets of jars for several different use cases, and for a 
consumer of the module to choose which use case aligns with their needs.

Thanks,
---
Kirby Files
Software Architect
Masergy Communications
kfiles@masergy.com

Mime
View raw message