On Sat, Nov 27, 2010 at 4:34 PM, John Shahid <[email protected]> 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. > 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. 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. 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 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. alex
