Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@ant.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Subject: Re: Solution to native dependencies with Ivy
From: Jeffrey Sinclair <jeff@cooljeff.co.uk>
To: ivy-user@ant.apache.org
In-Reply-To: <182251.97962.qm@web30803.mail.mud.yahoo.com>
References: <1249164876.6025.12.camel@Lini>
	 <182251.97962.qm@web30803.mail.mud.yahoo.com>
Content-Type: text/plain
Date: Tue, 04 Aug 2009 06:11:16 +0100
Message-Id: <1249362676.5990.15.camel@Lini>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

Thanks Maarten.

The push back that I would have to you guys is that if you were writing
a best practises document for how to use Ivy with JNI related
dependencies (and potentially in a non Java solution), would you be
advocating the use of extra:platform or using configurations?

If the former, then why not have platform as a first class citizen in
Ivy?

Having said this, the solution you've proposed would solve the problem
completely. To remove the complete gap of native dependencies in IvyDE,
would Xavier and yourself be happy with adding a new feature to IvyDE
which allows 'type' to be used in the same way IvyDE currently supports
javadoc and source attachments?

Then, in the future, if arbitrary filters are added to Ivy, we could
look into adding support for using custom filters (in addition to plain
type filters) in IvyDE.

Jeff

On Mon, 2009-08-03 at 14:35 -0700, Maarten Coene wrote:
> Jeff,
> 
> excellent blog entry, thanks for sharing this with us.
> 
> I suppose you want to make a proof-of-concept of your last proposal (mixture of types and 'platform' attribute).
> I don't like adding such a "platform" attribute to the set of default Ivy artifact-attributes since I don't think Ivy should have knowledge about this (I'm not talking about IvyDE here). But maybe you could make this 'platform' attribute custom/extra attribute and modify the retrieve/cachepath task to make it possible to filter on these extra attributes as well, which is a more general like for instance requested in https://issues.apache.org/jira/browse/IVY-439
> 
> regards,
> Maarten
> 
> 
> 
> 
> 
> ----- Original Message ----
> From: Jeffrey Sinclair <jeff@cooljeff.co.uk>
> To: ivy-user@ant.apache.org
> Sent: Sunday, August 2, 2009 12:14:36 AM
> Subject: Solution to native dependencies with Ivy
> 
> ivy-user,
> 
> The handling of artifacts to populate the java.libary.path has cropped
> up a couple of times on the mailgroup and there is an outstanding JIRA
> relating to this [IVY-600].
> 
> I'm finding that more people are being hit by this, in particular in
> Eclipse through IvyDE. I've come up with a solution that I feel will
> work well for both Ivy and IvyDE:
> 
> http://www.cooljeff.co.uk/2009/08/01/handling-native-dependencies-with-apache-ivy/
> 
> As described in the blog entry, I'd like to propose a mixture of using
> types as well as a new attribute on the artifact named platform.
> 
> I'd like to put a proof of concept together and hence would be grateful
> for any feedback on my proposal and evaluation of existing solutions.
> 
> Regards,
> 
> Jeff
> 
> 
>