I do agree that the majority of the documentation, if not all, is missing much needed platform specific considerations. A lot of people think that ANT is a java only build tool and they could also think that about IVY. When I first had to tackle this problem of handling platform specific issues, it would have been nice to have more information like best practices in the documentation.
With the feature set that is currently available in IVY, configurations is obviously the way to go. But is it worth it to add direct platform support to IVY instead of using configurations? I am more of a practical person than a purist, so I guess I would say yes. In the past, I even asked for symlink support to be added to IVY but was turned down. This led to my trigger approach, which works fine, but everybody else that needs to solve the same problem would have to duplicate my effort for themselves. Configurations could be considered a general solution to the platform specific problem. However, this general solution wasn't free. I had to do a lot of coding in ANT to support it and to get the features I wanted. Since this platform specific problem should be a common one that many people would need to solve, there should be a more direct way of solving with less effort on the build engineer. They all shouldn't have to come up with a similar configuration, trigger, and extra attribute solution that I did. Having built-in platform support would save everybody a lot of time and guarantee that everyone is solving it the best way. --- Shawn Castrianni -----Original Message----- From: Jeffrey Sinclair [mailto:[email protected]] Sent: Monday, August 03, 2009 12:48 AM To: [email protected] Subject: Re: Solution to native dependencies with Ivy 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 <[email protected]>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 > > > > ---------------------------------------------------------------------- This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.
