ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Garner, Shawn" <>
Subject RE: How to express a dependency on something like Gdata?
Date Tue, 07 Jun 2011 18:00:02 GMT
You could add a resolver specifically for that one with a relaxed pattern that will find pretty
much everything that is a jar.
Personally I didn't like the revision on the jars I just took it off the pattern for everything
that is using the Ivy Repository Layout.  They are still in a folder under the version but
I didn't see the need for the redundancy in the jar name.  Most JARs should have the version
inside the MANIFEST.MF anyway.

I did this for my Websphere runtime which consists of numerous other JARs which each could
be managed with their own ivy file and each has a version but that was too much work.  I didn't
use the wildcard like you did because I had specific JARs I wanted but it should work like
you have with a separate resolver and different repository layout pattern.


-----Original Message-----
From: James Apfel [] 
Sent: Tuesday, June 07, 2011 10:52 AM
Subject: How to express a dependency on something like Gdata?


I have a project that depends on Google's gdata-1.45.0 which is a
bunch of 43 different JARs and each JAR has its own version number. I
guess what I'm looking for is a way to say that my project depends on
gdata-1.45.0 and Ivy retrieves the 43 JARs for me without me having to
define each one individually such as gdata-calendar-2.0.jar.

I was looking into using something lile...

<dependency org="google" name="gdata" rev="1.45.0">
    <include name="*"/>

... but I don't think I understand what the purpose of <include/> is
and what it does.


-----Message Disclaimer-----

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act ("E-Sign")
unless a specific statement to the contrary is included in this message.

While this communication may be used to promote or market a transaction
or an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting,
or tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax, or accounting obligations and requirements.

View raw message