On Sat, 2010-11-27 at 17:46 -0800, Alex Boisvert wrote: > On Sat, Nov 27, 2010 at 4:34 PM, John Shahid <jvsha...@gmail.com> wrote: > > > Hi Alex, > > > > > Other than the transitive() method which resolves maven2 artifact > > > dependencies, there's no dependency management in the buildr core at the > > > moment. > > > > Is there anything in the trunk where I can start from ? > > > > No actual code, no. I have scraps on my laptop where I've started to > integrate Ivy code and persisting state into YAML file to lock and speed up > dependency resolution. When I have something ready to share, I'll push a > branch out on github. > > > If you need this feature today, I would suggest using the Ivy plugin. > > > > I noticed this plugin last week but didn't find any examples on how to > > use it with buildr, may be I should spend some time to try it out. > > > > You may want to take a look at: > https://github.com/stephenh/joist > as one example of using Ivy4r.
That's very helpful, thanks. > > > Dependency management is slated for our next major version (1.5.0) and I'm > > > hoping we'll have it done in Q1 2011. > > > > I'm interested on working on this issue. IMHO, without dependency > > management it is very unlikely that buildr will be used in production > > code. Which is sad because I think buildr offers a lot of nice features > > and the lack of dependency management is the only drawback I could find > > so far and it is easy to fix. > > > > The statement that "it is very unlikely that buildr will be used in > production code" is factually disprovable since buildr has already been > adopted and used in production in several environments already. More so, > Buildr was actually used in production environments at Intalio even before > it was brought to Apache 2 years ago. You're right, I meant wide adoption. I'm sure lot of people have found buildr features compelling to use in their production code, but the lack of dependency management prevents buildr from being a drop-in replacement for maven or ivy; Both of which are widely used in production. Even for new projects it is a tedious process to trace through tens of dependencies' pom files and creating a white list of dependencies. > > This being said, I won't dispute that dependency management is important and > critical to adoption. What I'll say is that Buildr was developed _without_ > automatic/transitive dependency management _by design_. Dependency > management was a total hell with Maven2 for years before I actually became > more stable. This isn't just a critique of the software but also how the > software is used by people. > > Beyond software bugs and limitations, few people/projects actually take the > time to correctly state their dependencies. Many projects get published in > public repos with invalid POMs, incorrect dependencies, too strict/lax > version requirements, etc. On large projects with many dependencies, it's > not uncommon for dependency management to become an anti-feature. People > spend more time excluding artifacts, adding missing ones, tweaking version > numbers, aliasing artifacts, adding missing repositories, or importing and > patching artifact into private repositories. This approach is referred to > as "black-listing" because you're essentially managing a list of exceptions. > And the world is full of exceptions. I can't disagree on this one, I've been there before. > > Buildr's current approach is often described as "white-listing". You have > to explicitly add artifacts and all required dependencies. There's no > hidden surprises, no unexpected change. Granted, it's more up-front work > and there's no "magical feeling" but in the long term, it entails less work > in my experience (and many others). With white-listing, builds become > much more deterministic than their back-listing counterparts. Builds that > work today will work tomorrow. They don't depend on someone's current > local M2 repo state. They don't depend on someone's installed list of > (snapshot) plugins, etc. I disagree. May be a better solution is to have a buildr task that resolve all transitive dependencies and have a human guide it through accepting or rejecting dependencies. The result of this task can be a lock file, something along the lines of what you're doing now (but more like Gemfile.lock). Again, managing white list of dependencies is a tedious process; Why do anyone have to pull pom files see dependencies and remember to update the white list every time a new dependency is added ? > > I hope this provides some background to explain why transitive dependency > management hasn't been implement yet. We've been meaning to support both > approaches for a long time but many other features have topped automatic > dependency management so far. It's not a feature we've overlooked. It's > not a feature we under-appreciate. From the start, we've been focused on > implementing features that support production build systems and those took > precedence over "nice to have" feature like automatic dependency management. > Yes, that was very helpful. Thank you. -JS
