ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <mgit...@gmail.com>
Subject Re: Solution to native dependencies with Ivy
Date Mon, 03 Aug 2009 03:11:56 GMT
I'm not really familiar with this problem space, but adding a peer to source
and javadoc for IvyDE integration--that sounds sensible to me.

Regarding the additional description that would need to be present in an Ivy
module descriptor to fully support a native library, again I've got to
believe that there's a generic way to accomplish that without resorting to
making the ivy.xml have special knowledge of native libraries. I mean, isn't
it fair to say that the ivy.xml XML schema in its current incarnation
doesn't have special knowledge of JARs? That is, JARs are just another
arbitrary type.

On Sun, Aug 2, 2009 at 3:20 PM, Jeffrey Sinclair <jeff@cooljeff.co.uk>wrote:

> Thanks Shawn and Mitch for your responses.
>
> It seems as if we are in agreement that the type attribute should
> identify that the artifact is a native library. In Shawn's case he has
> opted for type="bin". What there is debate over at the moment is how to
> declare artifacts being available for different platforms and how to go
> about resolving them.
>
> On the declaration side, I don't agree with Mitch that platform
> information is an application of the language. The fact is that a native
> artifact has some additional information that needs to be described in
> the module descriptor. An end user should be able to look at an ivy file
> and see what platforms an artifact is available for. This information
> must also be available in order to segregate artifacts with the same
> name and extension for the situation where you are building an
> application on several platforms using a shared cache location (e.g.
> afs).
>
> Shawn has opted to use configurations to identify which platforms an
> artifact is available for whereas I've opted to use an additional
> attribute. The main reason why I chose an extra attribute was because I
> can easily use this as my type token in a file system resolver. I do
> agree with Mitch that adding an extra attribute is probably not the
> right way to go but also don't completely like using configurations in
> the way we have them at the moment. Perhaps configurations are fine or
> in the future we will have conf-like attributes or functions on confs
> which will solve this general use-case.
>
> >From my perspective what I really want is a solution that will allow
> IvyDE to integrate with the java.library.path in Eclipse since this
> appears to be a major gap in the IDE integration. The ultimate solution
> of how we structure/resolve native libraries is likely to be constrained
> to the ivy-settings.xml file or in the end user's ivy.xml module
> descriptor. Hence it seems to me that in order to provide IvyDE
> integration, it would be sufficient enough to have a native library type
> filter in the preferences (just like we already have for javadocs and
> source). This would work regardless of the solution we come up with for
> how we structure the Ivy file.
>
> Would everyone be happy having this added as a feature to IvyDE or see
> any problems with this?
>
> Jeff
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message