Get list of all build variant dependencies (list of MavenCoordinates) in android build plugin

308 views
Skip to first unread message

Tomáš Procházka

unread,
Jul 6, 2017, 6:07:23 PM7/6/17
to adt-dev
Hi.

Does anybody known how to get list of dependencies per build variant in the new gradle plugin 3.0.0?

In 2.3.3 works this

 variant.getVariantData().variantDependency.packageDependencies.allAndroidDependencies
                                                               .allJavaDependencies

But it doesn't exist in the new plugin version.

I found just variant.compileConfiguration.dependencies.dump(); but it is empty and instead of MavenCoordinates return some weird Dependency class where classifier is missing.

Xavier Ducrohet

unread,
Jul 10, 2017, 11:49:10 AM7/10/17
to adt-dev
This is all internal APIs, and won't work in 3.0 where we changed the resolution to be lazy. You were accessing our internal model of the resolved dependencies.

variant.getCompileConfiguration returns the Configuration object. You'll have to resolve/query it for the dependencies. Just don't do it during configuration or your users won't be happy.

Look at Configuration.getIncoming().getArtifactView() to get a list of ResolvedArtifactResult.

Tomáš Procházka

unread,
Jul 12, 2017, 5:28:26 PM7/12/17
to adt-dev
Thanks a lot!!!!

I know that it is internal API, but there was (is) not an official public way how to do it.
We have internal system which collecting dependencies from all apps built on TeamCity to make overview which version and flavor  of our app use which version of the library, it helps a lot if we have same problem.

So I don't need i in the configuration time. I just need to have own task which will have this information.
I also need it just for variant which will be built actually.
I will check Configuration.getIncoming().getArtifactView(), but when is good task to access it on which task I should depend?


Dne pondělí 10. července 2017 17:49:10 UTC+2 Xavier Ducrohet napsal(a):

Tomáš Procházka

unread,
Aug 25, 2017, 3:30:39 PM8/25/17
to adt-dev
Which Configuration you exactly mean? There is a lot of Configuration classes, but no one with getIncoming() method. 


Dne pondělí 10. července 2017 17:49:10 UTC+2 Xavier Ducrohet napsal(a):
This is all internal APIs, and won't work in 3.0 where we changed the resolution to be lazy. You were accessing our internal model of the resolved dependencies.

Tomáš Procházka

unread,
Oct 17, 2017, 6:54:38 AM10/17/17
to adt-dev
Can you at least release source code when plugin is in RC now?
It is impossible to prepare migration to 3.0.0 four own gradle plugin without that before final release :-(

Or any snipped with example how to work with dependencies would be great too ;-)


Dne pátek 25. srpna 2017 21:30:39 UTC+2 Tomáš Procházka napsal(a):

Tomáš Procházka

unread,
Oct 25, 2017, 7:10:13 PM10/25/17
to adt-dev
So I was able to do it in this way

variant.getCompileConfiguration().getIncoming().getDependencies().each {
 println it.group + ":" + it.name + ":" + it.version
}

It iterates over Dependency class. But there is only group, name and version. Why it is not used normal MavenCoordinates class with classifier and packaging?
You probably also must know if it aar or jar or classifier.


Dne pondělí 10. července 2017 17:49:10 UTC+2 Xavier Ducrohet napsal(a):
This is all internal APIs, and won't work in 3.0 where we changed the resolution to be lazy. You were accessing our internal model of the resolved dependencies.

Tomáš Procházka

unread,
Nov 3, 2017, 5:11:18 PM11/3/17
to adt-dev
I end with this solution

List<MavenCoordinates> dependencies = new ArrayList<>()

variant.getCompileConfiguration().resolvedConfiguration.lenientConfiguration.allModuleDependencies.each {
ResolvedDependency dependency ->
try {
dependency.getModuleArtifacts().each { ResolvedArtifact artifact ->
MavenCoordinates newDep = new MavenCoordinatesImpl(dependency.moduleGroup, dependency.moduleName,
dependency.moduleVersion, artifact.type, artifact.classifier)

if (!dependencies.contains(newDep)) {
dependencies.add(newDep)
}
}
} catch (Exception ex) {
// no-op
}
}

try ... catch is nost best solution, but getModuleArtifacts(), will crash for example on project module dependencies.
Instead of try catch is maby possible to use dependency.getConfiguration().

I don't call this in configuration phase, but iside of my task.

Reply all
Reply to author
Forward
0 new messages