Return-Path: Delivered-To: apmail-ant-ivy-user-archive@www.apache.org Received: (qmail 26529 invoked from network); 18 Jun 2008 02:52:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 18 Jun 2008 02:52:46 -0000 Received: (qmail 78625 invoked by uid 500); 18 Jun 2008 02:52:48 -0000 Delivered-To: apmail-ant-ivy-user-archive@ant.apache.org Received: (qmail 78598 invoked by uid 500); 18 Jun 2008 02:52:48 -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 78587 invoked by uid 99); 18 Jun 2008 02:52:48 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Jun 2008 19:52:48 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of Nascif.AbousalhNeto@sas.com designates 149.173.6.148 as permitted sender) Received: from [149.173.6.148] (HELO mercav05.na.sas.com) (149.173.6.148) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 18 Jun 2008 02:51:59 +0000 Received: from merchub01.na.sas.com ([10.19.20.24]) by mercav05.na.sas.com with InterScan Message Security Suite; Tue, 17 Jun 2008 22:52:15 -0400 Received: from MERCMBX14.na.sas.com ([10.19.20.124]) by merchub01.na.sas.com ([10.19.20.24]) with mapi; Tue, 17 Jun 2008 22:52:15 -0400 From: Nascif Abousalh-Neto To: "ivy-user@ant.apache.org" Date: Tue, 17 Jun 2008 22:52:11 -0400 Subject: Reducing the number of resolves Thread-Topic: Reducing the number of resolves Thread-Index: AcjQF3dmNQmgjPZwRpCZv0NWVg9n8QAX4odQ Message-ID: <15412A37E8C9574393B24ADD991FAA760A261DBECD@MERCMBX14.na.sas.com> References: <26c776bf0806160359y6846c500p9fcbe4cb7f1636fd@mail.gmail.com> <20080617011238.GJ17513@jabba.hq.digizenstudio.com> In-Reply-To: <20080617011238.GJ17513@jabba.hq.digizenstudio.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org Hi all, We are trying to reduce the number of resolves that a developer needs to do= during its daily development cycle. Specially when hitting a remote reposi= tory, the time that a resolve takes adds up and affects productivity. We looked into decoupling resolves from compilation + publish (to local rep= o, for multi-projects in a developer playpen) but one of the issues we have= is the indirect dependency from a publish to the last resolve executed by = the client. The publish (or to be precise, the deliver) relies on state lef= t in memory by the last resolve. But since neither publish nor deliver allo= ws the specification of a resolveId, there is very little flexibility left = to really break up the steps. When we tried that it became easy for a second resolve to be executed in th= e middle and "corrupt" the state that would be used for the publish. The re= sult can be quite unsettling, like jars being published to the wrong module= ! Is this a known problem? I couldn't find anything about it in Jira. If so, = is there any recommended workaround?