How to get compile scope artifacts by Code?


(Seto) #1

ResolvedConfiguration resolvedConfiguration = project.getConfigurations()
.getByName(“compile”)
.getResolvedConfiguration();

It will include the stuffs for providedCompile as well.


(Stefan Oehme) #2

Either use sourceSets.compileClasspath (that’s the simplest if you only need a FileCollection) or configurations.compileClasspath (if you absolutely need a Configuration). compile no longer contains compileOnly in Gradle 3.4+

Also, don’t use configuration.resolvedConfiguration. Use configuration.incoming.


(Seto) #3

What’s the difference between configuration.resolvedConfiguration and configuration.incoming?
I found that incoming there’s no way to get first level module dependencies.

And also, compile does exclude compileOnly in Gradle 3.4+. But it still contains providedCompile with war plugin. Is there a way to get compile without providecCompile?


(Stefan Oehme) #4

The former is an old, inefficient API that we will deprecate/remove in the future.

incoming.resolutionResult.root.dependencies

compile.minus(providedCompile) for the files. There is no way to subtract the graph at the moment unfortunately, so you’d have to do some filtering yourself.


(Seto) #5

What does it mean subtract the graph?

To solve the problem of version conflict solution different from Maven. I write a plugin to retrieve the version from Aether. And I use eachDependency method to resolve the version conflict. Is there a way to judge whether it’s a first level module dependency or transitive dependency?

I can’t use resolvedConfiguration or incoming before it. Because it occurs before them.


(Stefan Oehme) #6

I wouldn’t do that, it would probably just slow down your build, because you would be working around all the caching we put in place. What problem are you facing?

What would be the reason for that distinction?


(Seto) #7


i don’t want to either. but check this thread. some transitive dependencies are resolved with incorrect version the original author intended. and it will make errors. and it blocks my work on wildfly-swarm maven plugin migration to gtadle.

only use aether for transitive dependencies.


(uklance) #8

If you wanted to benefit from caching you could use two tasks. One slow task which uses aether to resolve the dependencies and write a text/json/xml file with the result. And another to read the text file and create/update a configuration.

The first task could use inputs/outputs to benefit from up-to-date checks and could be compatible with the new build cache


(Seto) #9

I’m using eachDependency. It’s the same with spring one. And it will only occur once when I refresh the project. And also, I use collectRequest instead of dependencyRequest. It will only download the pom files. It won’t download jars. It’s much faster. And I think aether is with cache support already.


(Stefan Oehme) #10

Then instead of working around it/building plugins that reimplement version selection, it would be best if you filed a bug explaining the issue, so that we can fix it.


(Seto) #11


There’s already an issue created by uklance for it.
The problem blocking my work is the version resolved by Gradle is different from the Maven.
And there’s a task for Gradle plugin or a build for Maven plugin to use SwarmExecutor to run the project with classpath specified. But the problem is the version resolved by Gradle is not the same with Maven. And some dependencies’ versions are incorrectly resolved