ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffrey Sinclair <j...@cooljeff.co.uk>
Subject Re: Solution to native dependencies with Ivy
Date Mon, 03 Aug 2009 05:47:49 GMT
Mitch, I agree in its current incarnation the ivy schema doesn't have
any special knowledge of JARs. However we also have to admit that most
of the examples given in the documentation use artifacts that are
platform independent.

Shawn, you've got this to work with configurations. Would you have
prefered there to have been a direct way to associate platform specific
information at the artifact level or do you believe configurations are
the way to express this (perhaps with the need for a better way of
performing a projection over the artifacts pulled in).

I'm not saying the platform attribute is the way to go at this stage
(I'll probably update my blog to take into account the helpful feedback
given). My aim was to spark a little debate to see what other ways the
issue could be dealt with :)

Jeff

On Sun, 2009-08-02 at 20:11 -0700, Mitch Gitman wrote:
> 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
View raw message