+1 My personal view is that,
1) Buildr shouldn't force any dependency resolution framework on anybody. It should always be possible to use explicit dependency lists (aka whitelisting) -- either local files (non-Maven artifacts) or Maven artifacts -- or use 3rd-party plugins. 2) We should keep supporting and improving Maven artifact resolution in Buildr (core) because it's the most widely used distribution scheme in the Java world. If that means eventually reusing Aether to get real good interoperability, so be it. I'll say in passing that a great feature of any dependency resolution framework is to allow/support caching the results locally to avoid both recomputing and network usage every time. Ivy4r supports this (though it's not the default) and saves the result in YAML files (one per ivy conf). This has the advantage that you can easily peek into what dependencies are used at any time and if you check it into version control then you can also easily monitor dependency changes and keep dependencies consistent across multiple checkouts. alex On Wed, Nov 2, 2011 at 8:36 AM, Michael Guymon <michael.guy...@gmail.com>wrote: > > I could not agree more, Buildr should stay lean and mean. Enabling a big > dependency resolution framework should be optional. > > Right now Aether suffers from the same needy networking that Maven has. It > wants to check artifacts frequently for changes. While this can be a good > thing, it is not always an operation a project should have to do. > > --M > > > On 11/02/2011 09:26 AM, Chiaming Hsu wrote: > >> >> If this becomes part of the core of buildr as Peter suggested, would >> there be performance impact when not using transitive dependencies? >> >> I have large projects using buildr (migrated from Maven), and I did >> strictly white listing without any use of transitive dependencies. Buildr >> runs at least twice faster then Maven to build the same large project after >> migration and generates WAR artifacts about half of the size of Maven. I >> believe using white listing of dependencies without transitive plays a key >> role in the performance / compactness I saw. I don't want to lose this key >> benefit of using buildr. >> >> In a sense, I would like to see transitive dependencies being optional >> (as it is in buildr now) and avoid any performance impact for projects not >> using transitive dependencies, if we brought in more "Maven stuff" into >> core buildr library. >> >> Cheers, >> Chiaming Hsu >> >> >> >> ______________________________**__ >> From: Peter Donald<pe...@realityforge.org> >> To: dev@buildr.apache.org >> Sent: Tuesday, November 1, 2011 8:40 PM >> Subject: Re: Experiences with transitive dependencies in buildr >> >> Hi, >> >> On Sat, Oct 29, 2011 at 5:43 AM, Michael Guymon >> <michael.guy...@gmail.com> wrote: >> >>> The integration with buildr is crude and for some reason the rdoc is no >>> longer formated correct. I will update it to make it legible again. >>> >>> https://github.com/mguymon/**buildr-resolver<https://github.com/mguymon/buildr-resolver> >>> >> nice. >> >> This is the ruby wrapper for the Aether java libs, which buildr-resolver >>> depends on >>> >>> https://github.com/mguymon/**naether<https://github.com/mguymon/naether> >>> >> That is quite neat. I wonder if the core of buildr could move across >> to using (n)Aether and if there is much benefit from that? Last time I >> looked the project was still relatively volatile. What did you think >> of working with the library? >> >> The one advantage I see is that it would be using the same core as >> maven and thus guaranteed to be compatible (where as now we know there >> is scenarios where we are not quite right). >> >> >> >> >
