From ivy-user-return-5147-apmail-ant-ivy-user-archive=ant.apache.org@ant.apache.org Wed Apr 22 18:10:43 2009 Return-Path: Delivered-To: apmail-ant-ivy-user-archive@www.apache.org Received: (qmail 80786 invoked from network); 22 Apr 2009 18:10:43 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 22 Apr 2009 18:10:43 -0000 Received: (qmail 48478 invoked by uid 500); 22 Apr 2009 18:10:43 -0000 Delivered-To: apmail-ant-ivy-user-archive@ant.apache.org Received: (qmail 48428 invoked by uid 500); 22 Apr 2009 18:10:42 -0000 Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ivy-user@ant.apache.org Delivered-To: mailing list ivy-user@ant.apache.org Received: (qmail 48418 invoked by uid 99); 22 Apr 2009 18:10:42 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 Apr 2009 18:10:42 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of Kirby.Files@masergy.com designates 64.47.23.36 as permitted sender) Received: from [64.47.23.36] (HELO mtxexch01.masergy.com) (64.47.23.36) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 Apr 2009 18:10:31 +0000 Received: from [64.47.104.72] ([64.47.104.72]) by mtxexch01.masergy.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Apr 2009 13:10:10 -0500 Message-ID: <49EF5D80.1080201@masergy.com> Date: Wed, 22 Apr 2009 14:10:08 -0400 From: Kirby Files User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: ivy-user@ant.apache.org Subject: Re: Configurations and Ivy file confusion References: <49EF238A.5020908@tbee.org> <49EF2CA8.2080907@tbee.org> <49EF3982.2040301@masergy.com> <49EF4F77.4070005@tbee.org> In-Reply-To: <49EF4F77.4070005@tbee.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2009 18:10:10.0262 (UTC) FILETIME=[930F6760:01C9C375] X-Virus-Checked: Checked by ClamAV on apache.org 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: >> 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