https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# plugin-development
s
This message was deleted.
r
Detached configurations are kind of a mysterious feature. I was researching them over the weekend and there's not a lot of information out there
c
I think I’m comfortable with the detached configuration part… but it’s bugging me that plugins which want to do dynamic dependency lookup seem to be forced to do it through the applying projects repositories.
v
What is so mysterious about detached configurations? o_O They are simply not attached, i.e. they are not named, cannot be accessed by the build script, are not affected by 
configurations.all { ... }
and similar, because they are detached.
And I guess if you get the detached configuration from 
buildscript.configurations
instead of 
project.configurations
it might use the plugin repositories, but I didn't try. But should be testable quickly be resolving something that is not found and seeing in the error which repos were searched.
Yep
Copy code
buildscript.configurations.detachedConfiguration(dependencies.create("a:b:1")).resolve()
=>
Copy code
Could not resolve all files for configuration ':detachedConfiguration1'.
> Could not find a:b:1.
  Searched in the following locations:
    - <https://plugins.gradle.org/m2/a/b/1/b-1.pom>
    - <https://dl.google.com/dl/android/maven2/a/b/1/b-1.pom>
  Required by:
      project :
pluginManagement { repositories { ... } }
actually is 
buildscriptManagement { repositories { ... } }
:-D
r
What is so mysterious about detached configurations?
What problem they're trying to solve. As far as I can tell, the interesting thing about detached configurations isn't that they're detached, it's that they're dynamic. They allow plugins to resolve dependencies dynamically at execution time, as an implementation detail of whatever it is they do
The features you mentioned (they aren't named, they don't appear in 
configurations.all
) sound like visibility mechanisms to me. Java doesn't have detached methods, it has private methods
v
They can do the same with attached configurations
But with detached, well, it is detached
And it does not pollute the user-space configuration container
But also it does not allow the user to change it
Which can be good or can be bad
Java doesn't have detached methods, it has private methods
What point should that be? We are talking about a Gradle concept, not a Java concept, so I don't see any value in this comparison
But yeah, you probably can consider detached configurations as private configurations, because they are not attached to the public configuration container
c
Sorry - checking back in here… the issue I have with using a detached configuration from the host project is that it’s not really fully detached from the project as its rooted in the same repository set. If the user has restrictive rules about repositories and what can be resolved from where, they might have to change them to allow plugin dependencies to resolve.
and thanks (again!) @Vampire that works perfectly
v
That's correct, and most often also good. The user should have the control where dependencies are resolved from. Many companies for example have rules that only internal audited mirrors must be used. There is also a facility to have a detached repositories set, but that is currently just internal and not (yet, hopefully) exposed to the public API. If you really need to download independent, you need to use some utility, or a plain HttpClient or UrlConnection or similar.
c
yep… in this case I hit this when using a plugin with dynamically resolved Java implementation dependencies that forced addition of 
mavenCentral()
to the repository set when used against a “blank project” (in this case the root project).
3 Views
Open in Slack
PreviousNext
Powered by