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
nice.
This is the ruby wrapper for the Aether java libs, which buildr-resolver
depends on
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).
