Return-Path: Delivered-To: apmail-incubator-ivy-user-archive@locus.apache.org Received: (qmail 65334 invoked from network); 29 Aug 2007 12:59:52 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 29 Aug 2007 12:59:52 -0000 Received: (qmail 3537 invoked by uid 500); 29 Aug 2007 12:59:47 -0000 Delivered-To: apmail-incubator-ivy-user-archive@incubator.apache.org Received: (qmail 3518 invoked by uid 500); 29 Aug 2007 12:59:47 -0000 Mailing-List: contact ivy-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ivy-user@incubator.apache.org Delivered-To: mailing list ivy-user@incubator.apache.org Received: (qmail 3509 invoked by uid 99); 29 Aug 2007 12:59:47 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 29 Aug 2007 05:59:47 -0700 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 andyp@bea.com designates 66.248.192.39 as permitted sender) Received: from [66.248.192.39] (HELO repmmg02.bea.com) (66.248.192.39) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 29 Aug 2007 13:00:40 +0000 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l7TCxKw5030368 for ; Wed, 29 Aug 2007 05:59:20 -0700 Received: from eagle.bea.com ([172.24.28.21]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l7TCxHtX032627; Wed, 29 Aug 2007 05:59:18 -0700 Message-Id: <6.2.5.6.2.20070829135323.02d68528@bea.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 29 Aug 2007 13:59:45 +0100 To: ivy-user@incubator.apache.org From: Andy Piper Subject: Re: Problems with ivy:install Cc: ivy-user@incubator.apache.org In-Reply-To: <635a05060708290538v347f033av4cf8c59355e0d457@mail.gmail.co m> References: <6.2.5.6.2.20070815170855.02db6130@bea.com> <635a05060708150949y9447f0ctc745a5f0b4192546@mail.gmail.com> <6.2.5.6.2.20070815195315.02bd2e70@bea.com> <635a05060708160013j636e15f7r5abcdb347d4c863d@mail.gmail.com> <6.2.5.6.2.20070828132500.02ddb0f0@bea.com> <635a05060708280532i7f17f5efj330aa7b15e07c6ba@mail.gmail.com> <6.2.5.6.2.20070828134138.02e1d0a0@bea.com> <635a05060708282340m26a19038q8f615edeec013b81@mail.gmail.com> <6.2.5.6.2.20070829091738.02c7fea8@bea.com> <635a05060708290538v347f033av4cf8c59355e0d457@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org At 13:38 29/08/2007, Xavier Hanin wrote: >I think there's a problem of vocabulary. In Ivy terminology, you always >install from a repository *to* another one. Here you're talking about >installing from A and B. But to which repository? > >1. Without ivy:retrieve, nothing from B gets installed. > > >If install means copied from one repo to another, this is possible to do >with the install task. But you need to specify a chain of A and B as source >and another repo as destination. This is exactly what I have. A chain of A and B, but still nothing gets installed from B to my taregt. I am trying to install to shared (if it matters). >2. With ivy:retrieve everything gets installed from both A and B (but > > A is the repo I specified in the install task) > >Retrieve is used to copy artifacts to a loca destination (which can later be >used as a repository, but it's unknown by Ivy at the moment of the retrieve >call). ? I think this is my point. I understand what ivy:retrieve does, I don't understand why it has _any affect at all_ on what ivy:install does. The two are not conceptually related and yet clearly, based on my experiments, there are side effects of one to the other. >3. If I specify B as the repo in the install task then the build > > fails and nothing is installed. > > >Maybe it's because is lacking information about where to find information >about your modules, because B is not enough. The install task is very >similar to an inline resolve using only one repository, followed by a >publish of bunch of modules. If the resolve with only one repository does >not work, the install won't work. So you are saying that it should work, assuming my repositories and specification are correct? >For consistency I would expect either: > > > > a. For (2) only transitive modules in A to be installed > > > > or > > > > b. (3) to succeed and the source repo to be ignored when transitive > > is set to true. > > > > But, for the record, I don't want (a), I want (b). (2) is close > > enough, except that I would expect there to be an implicit retrieve. > > >I think you're confusing what install and retrieve are meant for. I don't >say they're obvious, but I think that by combining the resolve, retrieve and >install tasks you have a pretty flexible set of tools, with which you should I agree, but what is their relationship? I cannot find any documentation on how retrieve affects install. I think if I understood that then all would become clear. >be able to do what you want. Maybe if you explained what you want to do, we >could help by explaining which tasks are better suited? andy Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.