ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Damm <bd...@silverspringnet.com>
Subject Re: Is there a real(!) advantage of Ivy over placing the depends in the VCS
Date Fri, 11 Sep 2009 17:28:47 GMT
One aspect of using ivy that I've noticed is the larger the deployment, and 
the greater the integration into the product lines, the more a kind of 
emergent behaviour emerges.  Sometimes the source of the problem (which 
usually manifests itself as being unable to locate an artifact that is quite 
clearly there) is a problem with how ivy was configured, and sometimes it could 
be a user error (e.g. making the ivy-cache read only) but invariably the 
debugging of the problem takes much longer and consumes more development time 
than it ought to.

The benefits of an ivy system that's working well are very good, but whether 
they outweigh the time we've put into it is still under review.  I'm not sure 
yet what needs to change with ivy (or our specific ivy configuration) to ensure 
that the benefits unquestionably do outweigh the time put into the system, 
because the specific reasons that work stoppage occurs are so varied.

For comparison, the shop I am a part of has more than a dozen and less than 40 
developers.

Cheers,
-Ben

On Friday 11 September 2009 06:58:45 am Ben Evans wrote:
> Kirby Files <kfiles@masergy.com> wrote on 11/09/2009 14:45:09:
> > Sebastian Krysmanski wrote on 09/11/2009 04:16 AM:
> > > 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)
> >
> > I wouldn't really agree with this summary, but YMMV. Most people on
> > this list have come to find Ivy because of the issues they faced with
> > their previous build systems. Since you aren't seeing issues right
> > now, you are unlikely to find the learning curve of Ivy worthwhile.
>
> Agreed, but it's worth noting that the OP didn't provide much information
> about his/her
> project. What is appropriate for a 2-person shop writing a few CMS plugins
> to support their
> sales team is unlikely to be suitable for an enterprise group with
> hundreds of developers
> that requires a build system with integration hooks for IT management
> reporting and
> can enforce use of specific bundles of libraries, and which can get a new
> contract developer
> up and coding in a few hours (and comes with a pony, of course).
>
> > One thing that I haven't seen discussed, however, in this thread, is
> > synchronization of dependencies between build (Ant) and devlopment
> > (Eclipse). Before Ivy, we had a terrible time keeping classpaths in
> > sync. We'd have to update build scripts to check for the presence of
> > required jars, and also add the jars to the Eclipse project. The
> > latter task was frequently done haphazardly by junior developers in a
> > way that was specific to their own environment. The result was that a
> > developer checking out a project for the first time had some work to
> > do getting the classpath correct to be able to compile the project
> > within Eclipse (the build system was in better shape, since Continuous
> > Integration ensured the classpath was OK -- plus Ant has filesets).
> >
> > With the IvyDE plugin, this is hugely improved. All dependencies are
> > managed in the ivy.xml, which provides the classpath for both the
> > build system and the IDE.
>
> In my experience, this is true - the situation is much improved. However,
> as ever,
> the devil is in the detail, and in Java development, both devil and detail
> are
> classloading and its attendant issues.
>
> Ben

   
-- 
Benjamin Damm
Silver Spring Networks
650-298-4200 x201

Mime
View raw message