Return-Path: Delivered-To: apmail-ant-ivy-user-archive@www.apache.org Received: (qmail 21373 invoked from network); 6 Jul 2009 11:51:40 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 6 Jul 2009 11:51:40 -0000 Received: (qmail 87003 invoked by uid 500); 6 Jul 2009 11:51:50 -0000 Delivered-To: apmail-ant-ivy-user-archive@ant.apache.org Received: (qmail 86969 invoked by uid 500); 6 Jul 2009 11:51:50 -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 86959 invoked by uid 99); 6 Jul 2009 11:51:50 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Jul 2009 11:51:50 +0000 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: local policy) Received: from [195.248.191.95] (HELO mail.alkar.net) (195.248.191.95) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Jul 2009 11:51:41 +0000 Received: from [213.154.221.5] (HELO localhost) by mail.alkar.net (CommuniGate Pro SMTP 5.2.13) with ESMTP id 2011741147 for ivy-user@ant.apache.org; Mon, 06 Jul 2009 14:51:19 +0300 Date: Mon, 6 Jul 2009 14:51:14 +0300 From: Pavel Sharov X-Mailer: The Bat! (v2.00.6) Personal Reply-To: Pavel Sharov X-Priority: 3 (Normal) Message-ID: <163-1344473625.20090706145114@optima.com.ua> To: Tom Widmer Subject: Re: publish an extending conf In-Reply-To: References: <183-1862142687.20090630150320@optima.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Tom, thank you for your replies. I've created a feature request in Jira according to your suggestion. As for the workaround with wildcards that you proposed, it does not seem to work: the delivered ivy.xml contains no configurations assumed in this case. As far as I understand from the docs (dependency page), wildcards work individually as '*', but they don't as part of expression like 'X_*'. -Pavel TW> If you were to follow a suitable naming convention, you could do, say: TW> confs="X,X_*" TW> (the docs say that wildcards are supported, so hopefully that works). TW> Otherwise, you could raise a feature request to include a new attribute TW> on deliver and publish, something like includeRequiredConfs. TW> Tom