Return-Path: Delivered-To: apmail-ant-ivy-user-archive@www.apache.org Received: (qmail 70482 invoked from network); 4 Mar 2010 19:26:06 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 4 Mar 2010 19:26:06 -0000 Received: (qmail 10105 invoked by uid 500); 4 Mar 2010 19:25:55 -0000 Delivered-To: apmail-ant-ivy-user-archive@ant.apache.org Received: (qmail 10083 invoked by uid 500); 4 Mar 2010 19:25:55 -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 10075 invoked by uid 99); 4 Mar 2010 19:25:55 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Mar 2010 19:25:55 +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: local policy) Received: from [95.129.49.110] (HELO abode.nmhq.net) (95.129.49.110) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Mar 2010 19:25:47 +0000 Received: from matthies by abode.nmhq.net with local (Exim 4.69) (envelope-from ) id 1NnGfm-0004pD-ST for ivy-user@ant.apache.org; Thu, 04 Mar 2010 20:25:26 +0100 Date: Thu, 4 Mar 2010 20:25:26 +0100 From: Niklas Matthies To: ivy-user@ant.apache.org Subject: Re: advanced ivy retrieve syntax Message-ID: <20100304192526.GA18095@nmhq.net> Mail-Followup-To: ivy-user@ant.apache.org References: <27750721.post@talk.nabble.com> <27784758.post@talk.nabble.com> <27784895.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27784895.post@talk.nabble.com> X-Operating-System: Linux 2.6.31.5 x86_64 X-Editor: VIM - Vi IMproved 7.1 User-Agent: Mutt/1.5.18 (2008-05-17) X-Virus-Checked: Checked by ClamAV on apache.org On Thu 2010-03-04 at 10:44h, Juha Ranta wrote on ivy-user: : > Now that I thought of it, I'd like it if I could do something like this: > > e:localdir="mbeantypes"/> > > and then use the localdir or whatever extra attribute I defined in the > dependency in my retrieve task. > > I don't think it's always a good idea to expect that a single jar should > know whether it is placed in war, ear, APP-INF/lib, classpath, as a BEA > shared library, in the mbeantypes directory, in the classpath, or whatever, > and publish all the confs that the user may need. Well, can't the user instead define appropriate private confs in his module, one per target directory, with the respective dependencies, and then perform multiple retrieves, one for each conf? -- Niklas Matthies