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 <[email protected]> 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
