ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Widmer <tom.wid...@googlemail.com>
Subject Re: Is there a real(!) advantage of Ivy over placing the depends in the VCS
Date Mon, 14 Sep 2009 15:34:38 GMT
Sebastian Krysmanski wrote:
> Hi all,
> 
> thanks for all the answers. To just summarize for me what has been said
> (correct me, if I'm wrong):
> 
> * This big(gest) (and only?) disadvantage of storing the dependencies in a
> VCS is the time needed to checkout a project. 

This will be a serious problem if you are using a distributed VCS like 
Git, Bazaar or Mercurial - everyone will get every version you've ever 
used of every dependency when they do a checkout (aka clone).

Also, it's not just checkout speed, but also the speed of many other 
operations that will be improved (after I removed a tree of 5000 3rd 
party C++ include files from our main VCS tree and into ivy, svn status 
checking the tree sped up greatly).

It's faster when you don't
> have to check out all the dependencies. This is especially true when you
> have all (or most) dependencies already in your local dependency cache, or
> when you have multiple copies of the same library (because it's needed for
> multiple projects). This can, however, be solved (to a certain degree) by
> providing a central library/dependency directory in one's VCS repository
> that is being used by all projects. (So, no need to check out the same
> library multiple times.)

In ivy I actually have set things up so it amalgamates dependencies for 
multiple projects into a single directory for IDE use, as a performance 
enhancement (memory usage of the IDE is significantly reduced if it 
doesn't have to handle 10 copies of apache commons, etc!). Doing this 
was quite complex though.

> * To prevent libraries from disappearing from a public repository (not
> because Ivy deletes them but because the library's author deletes them or
> because the public repository cease to exist) one could create his/her own
> Maven/Ivy repository. However IMHO the effort needed to manage this
> repository is higher than managing the files in one's own VCS repository.

It will be simpler if you set up a (permanently) caching Maven 
repository server. That way, you get repeatable builds since the repo 
will never throw away any artifacts you've used, but it will also 
automatically obtain any missing libraries for you from public maven 
repositories. OTOH, the cost of setting up the repo server might 
outweight the benefit if you only have a small team (< 5 say). 
Unfortunately, I haven't set that up here - I have to semi-manually add 
libraries to our ivy repo (in that I have to run our generic 
install-into-repo script).

> And there's no advantage over placing the dependencies directly in the VCS
> repository.
> * Regarding the point "simpler Ant scripts": it depends on what you
> previously had. But I think "simply use the libraries you've just checked
> out" is as easy as it can get.

Well, that's true as long as your VCS tree contains the right 
combination of libraries - many 3rd party java libraries depend on other 
ones (e.g. log4j, apache commons, spring, etc.), and making sure you 
have the correct versions of everything (bearing in mind you can only 
have 1 version of each library) can require some manual work that is 
automated by ivy, at least when there is a good quality pom or ivy.xml 
file available that accurately describes the dependencies.

There's quite a good chance that you already have multiple copies of 
some classes in your dependencies folder, possibly some of them 
different versions, which can lead to inconsistent runtime behaviour 
depending on which version the JVM happens to load.

OTOH, problems in maven metadata tend to lead to these problems 
happening even if you are using ivy. Ivy Roundup does solve this - the 
metadata there looks correct.

  So I doubt that the Ant scripts get easier
> when they also have to download the necessary dependencies (instead of just
> using them). On the contrary: If you have multiple projects and want all
> projects to upgrade a certain dependency you have to modify all Ant scripts
> (to specify the new version); whereas if you place the dependencies in a
> single directory in your VCS repository you can simply replace the library
> and you're done. No need to modify any ant scripts (or any files at all).

If your software should all use the same library version, that's fine. 
But what if you have one project relying on A, which needs B version x, 
and one project relying on C, which needs B version y. You'll end up 
having to split up your dependencies directory, and start manually 
managing your dependencies (this is called jar hell, and java needs some 
kind of module support to completely get rid of the problem).

> So the tradeoff is:
> 
> * without Ivy: slower initial checkout; but easier to use (works out of the
> box) and easier to manage (simply place every necessary library in the VCS
> repository)
> * with Ivy: faster initial checkout; but not as easy to use (need to run Ivy
> at least once; need to run Ivy every time the dependencies' versions change)
> and more "difficult" to manage (it's prudent to setup a private repository
> which must be maintained/managed in some way)
> 
> So Ivy is a great help, when:
> 
> * one has multiple projects that can't (for some reason) share a single
> dependencies directory
> * the dependencies' versions change very often (although I think this is
> hardly the case)
> * one has a slow network connection to his/her VCS repository and/or the
> dependencies are really big in size (several megabytes)

* one has projects depending on other projects and one sometimes needs 
to build some project against an old version of another project (so you 
want to use the correct versions of dependencies of the other project to 
avoid breaking anything)
* One splits projects into small modules, and these are combined to make 
larger modules, etc. Managing (transitive) dependencies between the 
modules and 3rd party ones is now sane and somewhat automatic.
* You have a necessarily up to date and correct manifest of the 
dependency versions of all 3rd party code you use, making it easier to 
identify what 3rd party bugs might be in what of your software.

> Am I right about all this? Or am I missing something?

It's true that ivy adds lots of complication, and is overkill for many 
situations. If your needs are simple, then stick to a simple solution. 
If you ever find your simple solution no longer seems simple, you may 
find then that ivy reduces the complexity.

Tom


Mime
View raw message