ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Palmer <swpal...@gmail.com>
Subject Re: Building a Repo -- Excludes Question
Date Wed, 25 May 2011 16:03:50 GMT

On 2011-05-25, at 11:28 AM, Cody Casterline wrote:

>> 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?

Fetching from your Ivy/Maven repo should be as reliable as fetching from your SCM.  And you
use the best tool suited for each job.

> 
> * 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.

Right.. dependng on a public repo for builds I think is ridiculous.  The public repos should
only be used to populate your corporate repo or local repo.

>  Or worry, in the
> case of using a repo manager, that your sysadmin has gone in and "cleaned
> up" dependencies no longer used.

That shouldn't happen either.  You could just say that they cleaned up old revisions of the
source that were no longer used.  It's the same problem.

> 
> 
>> 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?

Unless you changed you replaced stuff you already had in your internal repo, of course you
should get the exact same things.  If you go and swap out commons-net-1.4.1.jar with another
different file that has the same name you will of course be screwing yourself. But is that
a real risk?

>  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 do say "yes :-) .. but if you don't trust the tool to do it's job then why use it?  It's
almost like fetching the dependences from the public repos on the internet, checking them
in with your code and not using a dependency manager locally at all.
Not exactly the same, since if you use the same lib in the next project it is nice to have
it locally in a system that knows the dependencies still.
  
> 
> 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.  :)

I think this is a good discussion… as my company is currently moving from the way you want
to do it (checking in dependencies) to using a separate dependency manager (ultimately a Maven
repo with Maven/Ivy/Gradle on the client side).  So it's good to hear other opinions while
we try to find the solution that is right for us.

I was pushing for Ant+Ivy because I find Maven too strict - anything slightly out of the ordinary
and they tell you to go write a plugin (e.g. it sucks for JNI stuff which we have a lot of).
 Though it looks like the Maven side may win for 100% Java projects.. the problem is we do
a lot of native code as well and none of these tools seem to have solved the dependency management
problem for native code.  I thought Ivy might be the most flexible.. but am now thinking of
using Gradle on the client side for the native code or anything that doesn't fit the project
structure that Maven decided was the "one true way"

Now I'm really getting off-topic though.. sorry… I'll shut up :-)

Cheers,

Scott



Mime
View raw message