Return-Path: X-Original-To: apmail-ant-ivy-user-archive@www.apache.org Delivered-To: apmail-ant-ivy-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 83B55C9D4 for ; Mon, 14 May 2012 18:32:44 +0000 (UTC) Received: (qmail 84486 invoked by uid 500); 14 May 2012 18:32:44 -0000 Delivered-To: apmail-ant-ivy-user-archive@ant.apache.org Received: (qmail 84202 invoked by uid 500); 14 May 2012 18:32:43 -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 84189 invoked by uid 99); 14 May 2012 18:32:43 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 May 2012 18:32:43 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of matt@thehurnes.com designates 209.85.215.45 as permitted sender) Received: from [209.85.215.45] (HELO mail-lpp01m010-f45.google.com) (209.85.215.45) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 May 2012 18:32:38 +0000 Received: by lahc1 with SMTP id c1so3903558lah.4 for ; Mon, 14 May 2012 11:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thehurnes.com; s=google; h=mime-version:x-originating-ip:from:date:message-id:subject:to :content-type; bh=qAzSowDJtyFhBGP0fq22D/2C4+Yrhg+LzxETi45h6W0=; b=XXU/UGYBxpN/BvIho2EcpgzMCRa0l2qexs5kjrKwmSIsfSdhE9cyMCfXrJAKuvKJpU QCuCmqgHk7X7eQZpDY9ZPvlpSYEMrWMjDdFfXEXKYi2Ygd/0x8ZpT4nEdXnnP9IXw8rR PAHqlksCypiG6UoWEisSzyXY7Dgu2KcCyXs2o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=qAzSowDJtyFhBGP0fq22D/2C4+Yrhg+LzxETi45h6W0=; b=hrs2LQAOXz/sSAuV5AsuCG6IfM3oXSP33p4BC6DYXa+v37MlMDltfv+4K6+44aTTtw 8mKku0Kgf3iglSF+OovRyR8yBGvOYa7Qs0+MGpJegwsaCoVtJy9Zc1NAHO0tdV8o8sST le35oP+b6B0Lc9Gt9Zqmr0o+jhUiYGW5su/p2gMTVW0KcAxnmWzWRz8XdMpC42Bz1kOa a8FL4UsbDZziIRP9w92b7vlN3c2hob/1bjA8Ju3be3+80uReP77Wd4+9gQgthxxKh9IU ZP2NTJ1lqyYG/fxESRSD5oJB28B0Mt352fSiobsBjxLXLnT6KtPkipIR+Lwf6vmbDsK6 8pGg== Received: by 10.112.83.229 with SMTP id t5mr4192917lby.8.1337020336038; Mon, 14 May 2012 11:32:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.28.133 with HTTP; Mon, 14 May 2012 11:31:55 -0700 (PDT) X-Originating-IP: [12.107.130.6] From: Matt Hurne Date: Mon, 14 May 2012 14:31:55 -0400 Message-ID: Subject: IvyDE seems to prefer artifacts in non-workspace-resolver over projects present in workspace To: ivy-user@ant.apache.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlBnnfzm0EWhe2/r9OKD2ob/FJI7+euyO/H7GJO76NdsVyfYy3rde2MS3TUf39tWkJUK2mh X-Virus-Checked: Checked by ClamAV on apache.org We are using Ivy to manage the dependencies of our projects on each other, and we're planning to use IvyDE as well. One of the resolvers we have in our Ivy configuration is used to publish our build artifacts to a local repository (with status "integration") so that they are available when building the projects that depend on them. In a clean environment, this repository is initially empty. If the local repository is empty and we configure IvyDE to resolve dependencies in the workspace, the projects do end up in the Ivy classpath containers of the projects that depend on them as expected. However, if we then build and publish the projects to the local repository and then perform a new resolve-all in Eclipse/IvyDE, the projects are removed from the Ivy classpath containers and the artifacts in the local repository take their places. Is this behavior expected/correct? Is there a way to ensure that IvyDE will always put workspace projects in the classpath container rather than artifacts with identical module revision IDs that exist in one of our configured repositories? If I were dealing with this type of scenario outside of Eclipse/IvyDE, I would look at putting the resolvers into a chain and using the "returnFirst" attribute to enforce a specific order. That's effectively what I'm looking to do with the workspace resolver. Is that possible? Thanks, Matt Hurne