Jeff, I think there are different possibilities when working with native libraries. Using extra attributes is one of them, but using configurations is another, and there are probably other solutions too. I think Ivy should give a choice to the user how these native libraries are handled, that's why I don't believe that platform should be a first class citizin in Ivy.
I don't do development on IvyDE, but it seems a usefull enhancement to me. I suggest you create a JIRA ticket for it... Maarten ----- Original Message ---- From: Jeffrey Sinclair <[email protected]> To: [email protected] Sent: Tuesday, August 4, 2009 7:11:16 AM Subject: Re: Solution to native dependencies with Ivy 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 <[email protected]> > To: [email protected] > 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 > > >
