Hi Lorant
There's quite a bit of work involved to get to the point where we can
substitute a project dependency for an external dependency. We've spent
some time discussing this, but it's not something we're currently working
on.
Daz
On Mon, Aug 4, 2014 at 6:03 PM, Lóránt Pintér <lorant.pin...@gmail.com>
wrote:
> Hi,
>
> With eachDependency { … } it was not possible to replace an external
> dependency with a project dependency. Will this be possible with this
> notation? It would be awesome if this was possible.
>
> --
> Lóránt
>
> On Monday 4 August 2014 at 11:30, Szczepan Faber wrote:
>
> Thanks Daz for input! Is the implementation of version-selection rules
> happening soon?
>
> It looks like that we're getting to consensus regarding the API:
>
> dependencies {
> components {
> modules(moduleSelectorNotation) { detailsObject ->
> detailsObject.replacedBy(moduleSelectorNotation)
> }
> }
> }
>
> 1. I'm curious if there is a plan to align dependency resolve rules
> and version selection rules in some way?
> 2. Do we want to use an existing imperative API
> "dependencies.components.eachComponent" as a way to pass down the
> 'replacedBy' declarations to the resolution algorithm? E.g.
> declarative data 'dependencies.components.modules' would form one of
> the 'eachComponent' rules behind the hood. Based on Adam's feedback, I
> assume that we _don't_ want to do this.
>
> Cheers!
>
> On Sun, Aug 3, 2014 at 11:09 PM, Daz DeBoer
> <darrell.deb...@gradleware.com> wrote:
>
>
>
>
> On Fri, Aug 1, 2014 at 5:18 AM, Szczepan Faber <szcze...@gmail.com> wrote:
>
>
>
> b) I would add some higher level api that would use a). For example:
>
> dependencies {
> components {
>
>
> modules("com.google.collections:google-collections").deprecatedBy("com.google.guava:guava")
> //or replacedBy(), supersededBy()
> }
> }
>
> Thoughts?
>
>
> We're designing a similar DSL for targeting version-selection rules to a
> particular module or set of modules
> (
> https://github.com/gradle/gradle/blob/master/design-docs/component-metadata.md#story-build-script-targets-versionselection-rule-to-particular-module
> ).
>
> I'm not sold on that DSL, but we do need a way to say "this block applies
> to
> _all_ modules".
>
> I guess we can either choose to use a string-based selector for choosing
> the
> modules that apply:
>
> dependencies {
> components/versions/some-other-rule-type {
> modules('*') {
> }
> modules('com.google.guava:*') {
> }
> modules('com.google.guava:guava') {
> }
> }
>
> Or use explicit parameters:
>
> dependencies {
> components/versions/some-other-rule-type {
> allModules {
> }
> group('com.google.guava') {
> }
> group('com.google.guave').name('guava') {
> }
> }
>
> I think I prefer the first approach. But we should definitely aim for
> consistency here.
> --
>
> Darrell (Daz) DeBoer
> http://www.gradleware.com
>
>
>
>
> --
> Szczepan Faber
> Core dev@gradle; Founder@mockito
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
--
Darrell (Daz) DeBoer
http://www.gradleware.com
