How to get compile scope artifacts by Code?

[Seto]

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

It will include the stuffs for providedCompile as well.

[st_oehme (Stefan Oehme)]

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]

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?

[st_oehme (Stefan Oehme)]

@Seto

What’s the difference between configuration.resolvedConfiguration and configuration.incoming?

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

@Seto

I found that incoming there’s no way to get first level module dependencies.

incoming.resolutionResult.root.dependencies

@Seto

Is there a way to get compile without providecCompile?

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]

@st_oehme

There is no way to subtract the graph at the moment unfortunately, so you’d have to do some filtering yourself.

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.

[st_oehme (Stefan Oehme)]

@Seto

To solve the problem of version conflict solution different from Maven.

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?

@Seto

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?

What would be the reason for that distinction?

[Seto]

@st_oehme

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?

Strange problem of Gradle compare with Maven

Here’s a solution that should work. I just wrote a plugin that uses Aether to resolve transitive dependencies instead of Gradle. Once resolved in Aether, the dependencies are added to a configuration in the gradle model with transitive=false Checkout the code from https://github.com/uklance/gradle-aether cd into the gradle-aether-sample directory run gradle dependencies --configuration compile Notice io.undertow:undertow-servlet:1.4.11.Final in the dependency list Usage apply plugin: com.l…

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.

@st_oehme

What would be the reason for that distinction?

only use aether for transitive dependencies.

[Lance (uklance)]

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]

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.

[st_oehme (Stefan Oehme)]

@Seto

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.

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]

Issue: Version selection differs from Maven, but also doesn't use latest

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