From ivy-user-return-5699-apmail-ant-ivy-user-archive=ant.apache.org@ant.apache.org Mon Aug 03 06:46:27 2009 Return-Path: Delivered-To: apmail-ant-ivy-user-archive@www.apache.org Received: (qmail 14895 invoked from network); 3 Aug 2009 06:46:27 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 3 Aug 2009 06:46:27 -0000 Received: (qmail 80950 invoked by uid 500); 3 Aug 2009 06:46:31 -0000 Delivered-To: apmail-ant-ivy-user-archive@ant.apache.org Received: (qmail 80870 invoked by uid 500); 3 Aug 2009 06:46:31 -0000 Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ivy-user@ant.apache.org Delivered-To: mailing list ivy-user@ant.apache.org Received: (qmail 80860 invoked by uid 99); 3 Aug 2009 06:46:31 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Aug 2009 06:46:31 +0000 X-ASF-Spam-Status: No, hits=-4.0 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of prvs=8466b4d98f=shawn.castrianni@halliburton.com designates 34.254.247.12 as permitted sender) Received: from [34.254.247.12] (HELO NP1MAIL002.halliburton.com) (34.254.247.12) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Aug 2009 06:46:21 +0000 Received: from NP1EXHU010.corp.halliburton.com (np1exhu010.corp.halliburton.com [34.34.132.66]) by NP1MAIL002 (8.14.3/8.14.3) with ESMTP id n736k0Yx030190 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 3 Aug 2009 01:46:00 -0500 Received: from NP1EXCH012.corp.halliburton.com ([34.34.132.75]) by NP1EXHU010.corp.halliburton.com ([34.34.132.66]) with mapi; Mon, 3 Aug 2009 01:46:00 -0500 From: Shawn Castrianni To: "'ivy-user@ant.apache.org'" Date: Mon, 3 Aug 2009 01:45:59 -0500 Subject: RE: Solution to native dependencies with Ivy Thread-Topic: Solution to native dependencies with Ivy Thread-Index: AcoT/gOxrHfmrkQSTzOD7A+Jpx2qnQABPjnw Message-ID: <34721A41A7BCF54ABC3B116219A8C1C2057EC490A5@NP1EXCH012.corp.halliburton.com> References: <1249164876.6025.12.camel@Lini> <7916a6a60908021032s35a02e72wbe8d5d2eb9d2c5a4@mail.gmail.com> <1249251628.6002.76.camel@Lini> <7916a6a60908022011i492bb05pceba115db7eddc51@mail.gmail.com> <1249278469.6110.12.camel@Lini> In-Reply-To: <1249278469.6110.12.camel@Lini> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-HALSTAMP: TRUE X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4,1.2.40,4.0.166 definitions=2009-08-03_01:2009-07-24,2009-08-03,2009-08-03 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0907200000 definitions=main-0908020229 X-Virus-Checked: Checked by ClamAV on apache.org I do agree that the majority of the documentation, if not all, is missing m= uch needed platform specific considerations. A lot of people think that AN= T 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, i= t 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 t= han a purist, so I guess I would say yes. In the past, I even asked for sy= mlink support to be added to IVY but was turned down. This led to my trigg= er approach, which works fine, but everybody else that needs to solve the s= ame problem would have to duplicate my effort for themselves. Configurations could be considered a general solution to the platform speci= fic problem. However, this general solution wasn't free. I had to do a lo= t of coding in ANT to support it and to get the features I wanted. Since t= his 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 effo= rt on the build engineer. They all shouldn't have to come up with a simila= r 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:jeff@cooljeff.co.uk]=20 Sent: Monday, August 03, 2009 12:48 AM To: ivy-user@ant.apache.org 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 sou= rce > and javadoc for IvyDE integration--that sounds sensible to me. >=20 > 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, is= n'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. >=20 > On Sun, Aug 2, 2009 at 3:20 PM, Jeffrey Sinclair wro= te: >=20 > > 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=3D"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 pri= vileged information for the sole use of the intended recipient. Any review= , use, distribution, or disclosure by others is strictly prohibited. If yo= u are not the intended recipient (or authorized to receive information for = the intended recipient), please contact the sender by reply e-mail and dele= te all copies of this message.