This sounds pretty good - some thoughts inline below
> Dependency Resolution
>
>* Dependency resolution is optional
>* Resolve Transitive Dependencies for an artifact(s)
>* Create/Rebuild a dependency file
>* Lock dependencies based on the dependency file
Transitive resolution should be capable of producing the same dependencies as
maven ( possibly via an interface compatible plugin ) and support the full
maven spec.
I'd add filtering and blacklist has been useful as well. I always have to
package(:war).libs.reject! { |lib| lib.group == 'servlet-api' } this is a
reasonable compile dependency that shouldn't get into runtime.
If the dependencies file something like the following
runtime:
- org.apache.cassandra:cassalndra-all:1.0.1
exclude:
- *:servlet-api:*
- *:junit:*
That would be pretty handy - I really like the idea of the dependency
report effectively acting as the whitelist / blacklist so when the universe
changes my build file doesn't necessarily have to :-)
>Maven interop
>
>* Generate a maven POM based on a Buildr project
>* Create & deploy maven friendly artifacts based on a Buildr project
>
>Would there be any benefit for having Ivy interoperability as well?
p
________________________________
From: Michael Guymon <[email protected]>
To: [email protected]
Sent: Thursday, 3 November 2011, 23:16
Subject: Re: Experiences with transitive dependencies in buildr
So based on the discussion, it sounds like the following solutions would work
well:
Dependency Resolution
* Dependency resolution is optional
* Resolve Transitive Dependencies for an artifact(s)
* Create/Rebuild a dependency file
* Lock dependencies based on the dependency file
Maven interop
* Generate a maven POM based on a Buildr project
* Create & deploy maven friendly artifacts based on a Buildr project
Would there be any benefit for having Ivy interoperability as well?
On 11/02/2011 09:59 PM, Peter Donald wrote:
> Hi,
>
> On Thu, Nov 3, 2011 at 12:26 AM, Chiaming Hsu<[email protected]> wrote:
>> If this becomes part of the core of buildr as Peter suggested, would there
>> be performance impact when not using transitive dependencies?
> I would hope not.
>
> I am not a huge fan of transitive closure across the builds when you
> can't lock it down to a specific set (like Gemfile.lock or what Ivy4r
> supports it seems). I don't object so much to the network chattiness
> but due to the un-reproducible of builds.
>
> Aether would mainly used as the API for interacting with Maven repos
> and for implementing transitive dependencies of maven artifacts.
>
>
