detecting change to configuration after it was resolved

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

detecting change to configuration after it was resolved

Szczepan Faber
Hey,

Currently, we don't detect a change to the configuration after it was
resolved, when the change happens within hierarchy. For example:

configurations {
  foo
  bar.extendsFrom foo
}

configurations.bar.resolve()
//add dependency to bar, via configuration hierarchy:
dependencies { foo "org.lib:1.0" }

Is this by design? I just came across a hard-to-debug problem related
to this. I would prefer if this scenario was better handled, perhaps
even by preventing the dependency addition. However, I may not see the
full picture.

Sometimes I wish that an explicit "resolve()" was required to get the
configuration resolved. Sometimes it's easy to trigger resolution
without even knowing.

Cheers!
--
Szczepan Faber
Core dev@gradle; Founder@mockito

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: detecting change to configuration after it was resolved

Luke Daley-2


On 22 August 2014 at 1:09:05 am, Szczepan Faber ([hidden email]) wrote:

Hey, 

Currently, we don't detect a change to the configuration after it was 
resolved, when the change happens within hierarchy. For example: 

configurations { 
foo 
bar.extendsFrom foo 
} 

configurations.bar.resolve() 
//add dependency to bar, via configuration hierarchy: 
dependencies { foo "org.lib:1.0" } 

Is this by design? I just came across a hard-to-debug problem related 
to this. I would prefer if this scenario was better handled, perhaps 
even by preventing the dependency addition. However, I may not see the 
full picture. 

Sometimes I wish that an explicit "resolve()" was required to get the 
configuration resolved. Sometimes it's easy to trigger resolution 
without even knowing.

In the new configuration approach this would be more explicit and we’d avoid this problem. All transformations are captured as “functions” (tasks really, but we have a name overloading problem), including dependency resolution. If you need the end result files for your function you’d declare this and we’d do the transform at the right time, similarly if you just need the resolved graph without the actual files. Basically, the implicit/on-demand approach that we use now goes away. This allows us to understand where the dependencies are going to be used.



Reply | Threaded
Open this post in threaded view
|

Re: detecting change to configuration after it was resolved

Adam Murdoch
In reply to this post by Szczepan Faber

On 22 Aug 2014, at 1:09 am, Szczepan Faber <[hidden email]> wrote:

Hey,

Currently, we don't detect a change to the configuration after it was
resolved, when the change happens within hierarchy. For example:

configurations {
 foo
 bar.extendsFrom foo
}

configurations.bar.resolve()
//add dependency to bar, via configuration hierarchy:
dependencies { foo "org.lib:1.0" }

Is this by design?

No, it’s a bug. There’s a similar bug when a configuration is reached via a project dependency.

Once a configuration is involved in a resolution, it should be locked and further mutations should fail. The error message could easily tell you why the configuration is locked as we have this information, and could possibly include clues as to where the resolution was triggered (for example, which build script or task happened to be running at the time, but not necessarily file and line number of the statement).


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
CTO Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com



Reply | Threaded
Open this post in threaded view
|

Re: detecting change to configuration after it was resolved

Szczepan Faber
Thanks for info!

Do you remember if there is a bug reported in jira about it? I haven't
found it but if you recall that it is already reported I'll look more
thoroughly.

Cheers!

On Fri, Aug 22, 2014 at 3:19 AM, Adam Murdoch
<[hidden email]> wrote:

>
> On 22 Aug 2014, at 1:09 am, Szczepan Faber <[hidden email]> wrote:
>
> Hey,
>
> Currently, we don't detect a change to the configuration after it was
> resolved, when the change happens within hierarchy. For example:
>
> configurations {
>  foo
>  bar.extendsFrom foo
> }
>
> configurations.bar.resolve()
> //add dependency to bar, via configuration hierarchy:
> dependencies { foo "org.lib:1.0" }
>
> Is this by design?
>
>
> No, it's a bug. There's a similar bug when a configuration is reached via a
> project dependency.
>
> Once a configuration is involved in a resolution, it should be locked and
> further mutations should fail. The error message could easily tell you why
> the configuration is locked as we have this information, and could possibly
> include clues as to where the resolution was triggered (for example, which
> build script or task happened to be running at the time, but not necessarily
> file and line number of the statement).
>
>
> --
> Adam Murdoch
> Gradle Co-founder
> http://www.gradle.org
> CTO Gradleware Inc. - Gradle Training, Support, Consulting
> http://www.gradleware.com
>
>
>



--
Szczepan Faber
Core dev@gradle; Founder@mockito

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: detecting change to configuration after it was resolved

Adam Murdoch

On 22 Aug 2014, at 4:27 pm, Szczepan Faber <[hidden email]> wrote:

Thanks for info!

Do you remember if there is a bug reported in jira about it? I haven't
found it but if you recall that it is already reported I'll look more
thoroughly.

via project dependency: https://issues.gradle.org/browse/GRADLE-1120



Cheers!

On Fri, Aug 22, 2014 at 3:19 AM, Adam Murdoch
<[hidden email]> wrote:

On 22 Aug 2014, at 1:09 am, Szczepan Faber <[hidden email]> wrote:

Hey,

Currently, we don't detect a change to the configuration after it was
resolved, when the change happens within hierarchy. For example:

configurations {
foo
bar.extendsFrom foo
}

configurations.bar.resolve()
//add dependency to bar, via configuration hierarchy:
dependencies { foo "org.lib:1.0" }

Is this by design?


No, it's a bug. There's a similar bug when a configuration is reached via a
project dependency.

Once a configuration is involved in a resolution, it should be locked and
further mutations should fail. The error message could easily tell you why
the configuration is locked as we have this information, and could possibly
include clues as to where the resolution was triggered (for example, which
build script or task happened to be running at the time, but not necessarily
file and line number of the statement).


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
CTO Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com






--
Szczepan Faber
Core dev@gradle; Founder@mockito

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email




--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
CTO Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com