Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@ant.apache.org
Received-SPF: pass (athena.apache.org: domain of topher1120@gmail.com
 designates 209.85.212.178 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=ayRgRUUb97xjcWKKmopRABAwsVX2deha9pH51lKqY3Y4mRW+un3ccjDlrftxsJr/Cr
         pLXfzB/HGyN+TYbniVde/y1p0jWks2Z9342bSDgkH9Bn42B9dLE5etcPma1woLTsWuh4
         Aqp3PmzEHBY/++e56kKeF6mtY/Of0vsAAcEMU=
MIME-Version: 1.0
In-Reply-To: 
 <6B4D8A42E536AC4EAC179B77DC162AB2793A8B@atl-mail03.corp.int-silverpop.com>
References: <000701ca320d$76926630$63b73290$@de>
	 <6B4D8A42E536AC4EAC179B77DC162AB2793A8B@atl-mail03.corp.int-silverpop.com>
Date: Thu, 10 Sep 2009 10:31:09 -0600
Message-ID: <f09ed26f0909100931k67fb4860yf8d18bced4f96ae1@mail.gmail.com>
Subject: Re: Is there a real(!) advantage of Ivy over placing the depends in
	the VCS
From: Chris Marks <topher1120@gmail.com>
To: ivy-user@ant.apache.org
Content-Type: multipart/alternative; boundary=00c09f971e1c29241004733bba19

--00c09f971e1c29241004733bba19
Content-Type: text/plain; charset=ISO-8859-1

To me, there are a couple advantages of using Ivy over VCS stored
dependencies.
 - faster checkouts from VCS, as mentioned previously.
 - a descriptive list of exactly what jars and versions of those jars are
required for your project.
 - simpler Ant scripts
 - easier inter-project dependency management (provided you have a private
Maven repository)

Faster Checkouts - as mentioned before, this is pretty obvious.  Especially
useful if you have a continuous integration server that does a clean
checkout for every build.  This cuts down on the turnaround time because the
CI server doesn't have to check out each jar again.
Descriptive list of dependencies and versions - I've been on projects where
we had to resurrect old projects and the jars were corrupted at some point.
Having to try to figure out what version of somelib.jar just from the name
can sometimes be tricky.
Simpler Ant scripts - by incorporating Ivy into my projects and using
configurations, it has made it easier for me to maintain Ant build scripts.
This is controversial, because I'm not sure if Ivy really helped me, or if
just giving my brain the exercise helped me create and maintain better build
scripts.
Easier library upgrades - If a new version of Junit comes out, I just flip
the rev number rather than having to download the new jar and commit it to
VCS.  I'm more likely to change the rev in a single file and see what breaks
than to find the web site, download the new library (most likely in a zip
that I have to then uncompress), copy it to my project directory and check
it in.
Easier inter-project dependency management - Most companies who use Maven
(and I suspect Ivy) have set up a private Maven repository.  I prefer
Artifactory (jfrog.org), but there are several out there to choose from.  If
you have that and have projects that rely on some internal core or utility
library, then you install the internal library to the Maven repository and
specify in the dependent project the dependency.  If the core or utility
library uses Ivy or Maven, it can publish snapshots and releases to the
Maven repository for your project to keep in sync as well, with no
additional hoopla to go through for Ant to download the latest library from
some random location in order to build.

The choice is always up to you, but these are my reasons why my projects use
Ivy.

Thanks,
topher


On Thu, Sep 10, 2009 at 6:22 AM, Carlton Brown <cbrown@silverpop.com> wrote:

> > -----Original Message-----
> > From: Sebastian Krysmanski [mailto:sebastian@krysmanski.de]
> > Sent: Thursday, September 10, 2009 7:55 AM
> > To: ivy-user@ant.apache.org
> > Subject: Is there a real(!) advantage of Ivy over placing the depends
> > in the VCS
> >
> > Hello,
> >
> > recently someone recommended Ivy to me because he saw that we were
> > hosting
> > our project dependencies in our Subversion repository. I took this
> > opportunity to have a look at Ivy and on first glance Ivy seemed very
> > nice.
> > However I see a major disadvantage over dependencies in a VCS
> > repository: If
> > a project is dormant for a longer period of time an artifact (i.e. a
> > library) may longer be available (in a certain, required version or
> the
> > repository may not exist anymore).
> >
> > If we were using Ivy this would result in the project no longer being
> > able
> > to be built.
>
> Why do you think that using Ivy might cause the required version not to
> exist anymore?  Ivy has no explicit or implicit behavior for deleting
> artifacts from the repository (cache yes, but not repository).
>
> > How does Ivy "address" this drawback? Is
> > there any commonly used solution to solve this problem?
>
> Ivy doesn't really address it, because Ivy isn't a repository manager.
> I do agree with the concern that in Ivy (or Maven, for that matter),
> where anyone could manipulate or remove the artifacts without an audit
> trail.   Your process and procedures ideally take care of this, but IMO
> it's a lot to leave to chance.   A practice I'd like to try is to use
> filesystem only for temporary artifacts, and IvySvn to store "permanent"
> artifacts.
>
> Another concern for me is the overhead of maintaining stable third-party
> artifacts in a metadata-indexed repository.   I have found that 99% of
> the time, I don't require transitive resolution or different
> configurations for things like log4j.   As long as its version number is
> stored in the manifest, then there's really no benefit in storing those
> things separate from the source code, and it adds a penalty of
> resolving/downloading something that could just remain tightly coupled
> to source.
>
> HTH,
> Carlton
>
> ***CONFIDENTIALITY NOTICE and DISCLAIMER***
> This message and any attachment are confidential and may be
> privileged or otherwise protected from disclosure and solely for
> the use of the person(s) or entity to whom it is intended. If you
> have received this message in error and are not the intended
> recipient, please notify the sender immediately and delete this
> message and any attachment from your system. If you are not the
> intended recipient, be advised that any use of this message is
> prohibited and may be unlawful, and you must not copy this
> message or attachment or disclose the contents to any other person.
>

--00c09f971e1c29241004733bba19--