ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebastian Krysmanski" <sebast...@krysmanski.de>
Subject AW: Is there a real(!) advantage of Ivy over placing the depends in the VCS
Date Fri, 11 Sep 2009 08:53:15 GMT
Thanks for the insight. This was really helpful. In your case I can see why
you want to use Ivy. Fortunately(?) we don't have such requirements in our
project. So, I think we'll stick with placing our libraries in our VCS.

Regards
Sebastian

-----Urspr√ľngliche Nachricht-----
Von: Shawn Castrianni [mailto:Shawn.Castrianni@halliburton.com] 
Gesendet: Freitag, 11. September 2009 10:47
An: 'ivy-user@ant.apache.org'
Betreff: RE: Is there a real(!) advantage of Ivy over placing the depends in
the VCS

I use IVY heavily for my entire corporate R&D group.  I designed all the ANT
scripts for the entire company and would not think of going back to checking
in dependencies into a VCS.  My reaction to this summary is that it is
mostly true, but it depends on what your environment and requirements are.



If you have a small project that ONLY has thirdparty dependencies that don't
change much (as you stated) then IVY probably doesn't have that much benefit
over checking these thirdparty dependencies into a central VCS that all of
your small projects can share.  The reason your thirdparty dependencies
would not change much is that you are not building them every day in a
continuous integration build system because they are thirdparty.  Where IVY
really has the advantage is in a continuous integration build system with a
modular build framework.  In other words, if you have several independently
buildable modules that depend on each other in some dependency chain that
you need to continuously build every day, IVY is the BEST!  Each module
build of the dependency chain can track which builds of the other modules in
that chain were used for the build.  Not only can these modules be dependent
on the other modules that you are building, but also be dependent on
thirdparty dependencies as described in the first scenario.  IVY can also
manage that by referencing these thirdparty dependencies from a public IVY
repository or creating your own thirdparty IVY repository.  This management
of the complex dependency chain of the internal modules is handled nicely by
IVY's transitive dependency management.  This transitive dependency
management cannot easily be achieved with a simple VCS dependency system.



My corporate environment/requirements are:



1.  several products each with multiple modules being combined together to
form a unified installer

2.  several separate simultaneous releases of this same product

3.  each release can use a different combination of branch/tag/trunk of each
module being combined together

4.  each module can reference other modules as dependencies

5.  each module can reference thirdparty dependencies

6.  thirdparty dependencies must be tightly controlled for legal reasons and
cannot be referenced from a public repository or freely downloaded from the
Internet by anyone

7.  100% trackable builds so that each module records the necessary metadata
to track each of its dependencies (whether internal dependencies in the form
of other modules in the dependency chain or thirdparty dependencies) back to
the specific revision of each source file





By the way, I accomplished #6 by allowing only an authorized person to
download thirdparty dependencies from the Internet after its license being
analyzed by our legal department to verify it was safe to use in commercial
software distribution.  These approved thirdparty dependencies would then be
checked into a SVN repository in the format of an IVY repository.  I use the
IVY+SVN plugin to IVY to allow these thirdparty dependencies to be
dynamically pulled from an SVN repository during the dependencies phase of
each module's build.





In order to accomplish all of the above (if possible at all) with just a VCS
repository of dependencies would require a nightmare of managing all of the
different combinations of dependencies (both thirdparty and internal),
required by each simultaneous release, in the VCS repository with tons of
branches or tags.



---

Shawn Castrianni



-----Original Message-----
From: Sebastian Krysmanski [mailto:sebastian@krysmanski.de]
Sent: Friday, September 11, 2009 3:16 AM
To: ivy-user@ant.apache.org
Subject: RE: Is there a real(!) advantage of Ivy over placing the depends in
the VCS



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

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

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



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)



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



Regards

Sebastian



-----Urspr√ľngliche Nachricht-----

Von: Chris Marks [mailto:topher1120@gmail.com]

Gesendet: Donnerstag, 10. September 2009 18:31

An: ivy-user@ant.apache.org

Betreff: Re: Is there a real(!) advantage of Ivy over placing the depends in

the VCS



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.

>


----------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and
privileged information for the sole use of the intended recipient.  Any
review, use, distribution, or disclosure by others is strictly prohibited.
If you are not the intended recipient (or authorized to receive information
for the intended recipient), please contact the sender by reply e-mail and
delete all copies of this message.


Mime
View raw message