ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cody Casterline <cody.casterl...@gmail.com>
Subject Re: Building a Repo -- Excludes Question
Date Wed, 25 May 2011 15:28:56 GMT
>
> Checking in the repo defeats it's purpose.


That depends on your purpose for using Ivy (or Maven or whatever). :)  I
want it to:

1) Easily fetch a library and its dependencies the first time I need use
it.
2) Handle transitive dependencies for those libraries so that I can just
declare a dependency on BobsWidget, and not the dozens of libraries *it*
depends on. (In this case, Apache CXF is what finally prompted me to look
into Maven and Ivy.)
3) And handle those transitive dependencies between our own sub-projects.


>  One of the reasons to use a dependency manager is to keep stuff that isn't
> source code out of your source control system.  A good rule of thumb is that
> if it doesn't create a readable "diff" it probably doesn't belong in your
> SCM. (Icons, images, sound effects, small media files being an allowable
> exception.)
>

I used to think that too.  Then I started working at my current company,
where they check all dependencies into the SCM.  I was horrified at first,
but I've actually since realized that it's a good practice for two very
important reasons:

* Build stability -- Your build never fails because some dependency isn't
present.  Everything required to build a our code is checked in with our
code.  You wouldn't not check in some of your code and require fetching it
before compiling.  Why do that with your JARs?

* Build reproducibility -- When you are trying to track down where a bug was
introduced, or need to do another build of an old version, the libraries
used to do that build are present.   You don't have to worry about whether
the public maven repo still has that old dependency in it.  Or worry, in the
case of using a repo manager, that your sysadmin has gone in and "cleaned
up" dependencies no longer used.


> Ask your self what you are getting by checking-in your Ivy repo?
>  Versioning? No, the ivy repo handles versioning of the resources
> internally.  You are basically just making a redundant copy… but your SCM
> isn't a backup tool.
>

Yes!  Versioning!   Including versioning of the dependencies used to build
the project.   You say "the ivy repo handles versioning of the resources
internally" -- but does it?  If I check out the project on another computer
and  ivy:resolve, am I guaranteed to get the exact same things I got on a
build I did years ago?  Even if you say "yes", please pardon me if I don't
believe you and rely on my own history (via my SCM) to verify that.   :)

I wish I could find a link to someone making the argument better than I am.
 (I would've sworn that my coworkers pointed me to one when I first made
your argument here.)  But it really just boils down to reducing external
dependencies and moving parts from your project to make for a more stable,
reproducible build environment.

 - Cody

P.S.: I realize I may have gone a bit off-topic for ivy-user.  But I heard
the same arguments when I was asking questions to the Maven community, and
Geoff brought up the same issues, so it seems somewhat relevant?  Well, now
that I think about it -- I guess it's very relevant in that it's something I
want to do with Ivy.  :)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message