I am building a plugin to collect all dependencies (including transative dependencies) in order to get an offline maven repository from all the dependencies of all the modules in my multi-module gradle build.
val configurations = (project.configurations + project.buildscript.configurations)
val allDependencies = configurations
.flatMap { configuration ->
configuration.allDependencies
}
.filterIsInstance<ExternalModuleDependency>()
.distinctBy { listOf(it.group, it.name, it.version) }
val detachedConfig = project.configurations.detachedConfiguration(*allDependencies.toTypedArray())
detachedConfig.resolvedConfiguration.resolvedArtifacts.forEach { resolvedArtifact ->
val id = resolvedArtifact.moduleVersion.id
val componentId = DefaultModuleComponentIdentifier.newId(
DefaultModuleVersionIdentifier.newId(
id.group,
id.name,
id.version,
),
)
logger.lifecycle("Component: ${componentId}, file: ${resolvedArtifact.file}")
}
When trying to invoke the code above with platform the version is always null
When trying with version catalog the version is the version.ref
Is there way to resolve the version into the real version number (preferably when working with the new version catalog version, but i can also revert to platform with a bom)
The platforms are imported as dependency constraints, so you probably need to additionally copy over the dependency constraints.
But actually your tactic might not be optimal anyway.
If you for example have dependency on A v1 in your production dependencies and on A v2 in your build script dependencies, then by throwing them together in one configuration you will end up with only A v2 in your result.
You probably should just iterate over the resolvable configurations and use their resolution result to build your offline repository or use one of the existing plugins that do this for you.
No sorry, I think I remember I have seen 2 or 3 such plugins in the past, but I never used them as I don’t see the benefit.
And I’m not going to implement that plugin for you, as I’m not even interested to use that for my own builds, unless you pay me for writing your code of course.
I already gave you the pointers you should need.
And here is even a doc chapter about accessing the resolution result: Gradle User Manual: Version 7.0
Yep, that looks more like the proper way I think.
Of course you only catch the production dependencies.
You don’t catch things like build script dependencies (each script can have its own) or detached configurations plugins or tasks create.