ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Goldstein <>
Subject conf versus extra attributes
Date Fri, 27 Aug 2010 00:36:04 GMT
I'm working on enhancing my ivy infrastructure to support native code libraries.  I've seen
a number of posts on how others have accomplished this and while analyzing those and thinking
of my own design, a question occurred to me.

In my mind, I feel that I'm greatly simplifying the comparison between  extra attributes and
conf.  For instance, if I had a library that was specific to Linux, I could represent it with
one of the following:

    <artifact org="someorg" name="somelib" type="so" rev="1.0" conf="linux"/>


     <artifact org="someorg" name="somelib" type="so" rev="1.0 extra:os="linux" conf="default"/>

On the surface, these seem to provide very similar functionality.  Ultimately, though, I'm
concerned that I'm missing some important fundamental difference that is going to cause me
headaches later on if I make the wrong decision on which one to use.

So, here my questions:

1.        What are the trade offs of the two approaches above?

2.       Are there fundamental differences between these two approaches in how ivy behaves?

3.       Are there fundamental differences in what each would provide to a client of a library
with this artifact?

4.       When choosing between the two, is there a best practice that would dictate when to
use one of the other?



- --------------------------------------------------------------------
The information contained in this electronic message and any attachments to this message are
intended for the exclusive use of the addressee(s) and may contain confidential or privileged
information. No representation is made on its accuracy or completeness of the information
contained in this electronic message. Certain assumptions may have been made in the preparation
of this material as at this date, and are subject to change without notice. If you are not
the intended recipient, you are hereby notified that any dissemination, distribution or copying
of this e-mail and any attachment(s) is strictly prohibited. Please reply to the sender at
NextLabs Inc and destroy all copies of this message and any attachments from your system.
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message