Separate compile and runtime dependencies of external modules

[NHendricks]

If I declare a compile dependency (e.g. to io.reactivex:rxnetty:0.4.19) I see that gradle also puts all transitive runtime dependencies into the compile configuration (in this case for example io.reactivex:rxjava:1.0.17).

Expected Behavior

Example:
dependencies {compile 'io.reactivex:rxnetty:0.4.19'}
My Java Code using the class rx.exceptions.Exceptions should not compile.
The compile should fail because the dependency io.reactivex:rxnetty:0.4.19 provides only runtime dependencies and rx.exceptions.Exceptions is part of io.reactivex:rxjava.

Current Behavior

The transitive runtime dependencies are added to the compile configuration. They should not be added to the compile configuration.

Context

It leads to unwanted dependendencies and has a reasonable impact for the migration to gradle in our company regarding tool acceptance and management of our dependencies.

Steps to Reproduce (for bugs)

I will upload a sample project here.

Your Environment

There is no specific environment needed. A pure call of gradle dependencies in the sample project shows the tree including the transitive runtime dependencies in the compile configuration.
gradle_example.zip

• Build scan URL:

[oehme]

We are actively working on this, so you can expect a fix in Gradle 3.4.

[eriwen]

@oehme Assigning to you to follow up on this issue when it's status changes.

[oehme]

This is fixed for project dependencies in 3.4 if you use the new java-library plugin. We still need to fix it for external dependencies (e.g. separating compile and runtime scope for Maven dependencies).

[eriwen]

@oehme Is this still scheduled for 4.0?

[oehme]

I don't think we'll be able to make it. 4.1 seems more realistic.

[eriwen]

@oehme cool, moved

[jjohannes]

This is now implemented (see #3360). Please feel free to give the latest nightly a try.

It will be in 4.5, but we will only make it the default behavior in 5.0 as it might break existing builds.

If you want to try, you can switch the behavior on by adding this to your settings.gradle:
gradle.experimentalFeatures.enable()

(4.6 will include this opt-in switch as well but the syntax might change for the release)

[julioromano]

What is the syntax of the opt in switch in 4.5-rc-2 ?

[jjohannes]

In the end, we did not make any changes for 4.5. It's still gradle.experimentalFeatures.enable().

4.6 will include an "official" way to enable this. I updated the comment above.

[oehme]

Closing the loop here, Gradle 4.6 added

enableFeaturePreview('IMPROVED_POM_SUPPORT') in settings.gradle

for this. Gradle 5.0 will make it the default.

[robstoll]

@oehme you mentioned in feb 2017

We still need to fix it for external dependencies (e.g. separating compile and runtime scope for Maven dependencies).

Is this fixed by now and if so, what do I need to do that maven <scope>runtime</scope> dependencies are not treated as compile?

[oehme]

This is for external dependencies, see the title of the issue and my last message.

[robstoll]

Well then, it still does not work with 4.5.1
I got a maven project which has a dependency defined as <scope>runtime</scope>, I have put gradle.experimentalFeatures.enable() in my gradle.properties. I am depending on the maven project and can still access code from the dependency defined in scope runtime.

[robstoll]

Man... my fault, I should have put it in settings.gradle => works. Sorry for the noise

[trevjonez]

I am seeing this issue with an android project using 4.9 with or without the improved pom support feature flag.

I have a failing test case in my plugin project, specifically this test

you can see I am expecting:

debugCompileClasspath - Resolved configuration for compilation for variant: debug
\--- com.trevjonez:and-lib:0.1.0 //pom redirects to default config
     \--- com.trevjonez:and-lib_release:0.1.0 //default config
          \--- io.reactivex.rxjava2:rxjava:2.2.0 //api dependency
               \--- org.reactivestreams:reactive-streams:1.0.2

but compile resolves to the same as runtime:

debugRuntimeClasspath - Resolved configuration for runtime for variant: debug
\--- com.trevjonez:and-lib:0.1.0
     \--- com.trevjonez:and-lib_release:0.1.0
          +--- io.reactivex.rxjava2:rxjava:2.2.0
          |    \--- org.reactivestreams:reactive-streams:1.0.2
          \--- com.squareup.moshi:moshi:1.6.0
               \--- com.squareup.okio:okio:1.14.0

[oehme]

@trevjonez Sorry, I don't see the problem. The compile classpath contains your api dependency and the runtime classpath contains your implementation dependency, just as expected.

[trevjonez]

@oehme I didn't do a good job of explaining it. I am expecting debugCompileClasspath to resolve as:

\--- com.trevjonez:and-lib:0.1.0
     \--- com.trevjonez:and-lib_release:0.1.0
          \--- io.reactivex.rxjava2:rxjava:2.2.0
               \--- org.reactivestreams:reactive-streams:1.0.2

but it is resolving as:

\--- com.trevjonez:and-lib:0.1.0
     \--- com.trevjonez:and-lib_release:0.1.0
          +--- io.reactivex.rxjava2:rxjava:2.2.0
          |    \--- org.reactivestreams:reactive-streams:1.0.2
          \--- com.squareup.moshi:moshi:1.6.0
               \--- com.squareup.okio:okio:1.14.0

all of the implementation dependencies are being exposed on the compile classpath as well as the runtime classpath.

[oehme]

Are you sure you linked the right test case? I only see asserts on files being there.

[trevjonez]

oops, I linked to master and had removed the asserts last night. I updated the original link with this commit specific url

[trevjonez]

@oehme
here is a build scan for the library publishing build:
https://scans.gradle.com/s/3x4vcfaxtgt5m/

here is a build scan for the consuming application via pom build: https://scans.gradle.com/s/mfmp2gtq2duwk/dependencies?toggled=W1swXSxbMCw3XSxbMCw3LFswXV0sWzAsNyxbMCwxXV0sWzAsNyxbMCwxLDRdXSxbMCw3LFswLDEsMl1dLFswLDhdLFswLDgsWzBdXSxbMCw4LFswLDFdXSxbMCw4LFswLDEsNF1dLFswLDgsWzAsMSwyXV1d

compared to the app consuming via .module meta info build: https://scans.gradle.com/s/ie7iohkxrq5e6/dependencies?toggled=W1swXSxbMCw3XSxbMCw3LFswXV0sWzAsNyxbMCwxXV0sWzAsNyxbMCwxLDJdXSxbMCw4XSxbMCw4LFswXV0sWzAsOCxbMCwxXV1d

[oehme]

Your plugin only defines a single usage context, redirecting to the default variant of the library, which is a runtime variant.

[trevjonez]

so I went that route so that I could still support consumers depending on the library without specifying the default variant artifact directly. I opened this issue explaining the issue I was seeing when publishing the same artifact under both the root component and release variant. #6389

[oehme]

Have you checked whether the POM for that default variant actually has properly separated <compile>/<runtime> dependencies? Just making sure this is not a problem on the publishing side.

[trevjonez]

I did yea. Here is a gist with the relevant POM files and the .module so you can see what is placed there in order for me to generate a usable POM given the issues from 6389.

https://gist.github.com/trevjonez/62b3d7907c13ca0728139d85ddf9cfbb

[oehme]

Can you try consuming that lib from a plain Java project? Just making sure this issue is not specific to the Android plugin.

[trevjonez]

looks like a java library is also pulling in all the runtime transitives as compile dependencies

https://scans.gradle.com/s/dmsu7idjx2c2k/dependencies?toggled=W1swXSxbMCwxXSxbMCwxLFswXV0sWzAsMSxbMCwxXV0sWzAsMSxbMCwxLDRdXSxbMCwxLFswLDEsMl1dXQ

scan from java-lib project after modifications in this commit

[oehme]

@melix I'm afraid I'll need some help here. We have a POM that has a <compile> and a <runtime> dependency. A Java library project depends on this and it uses IMPROVED_POM_SUPPORT, but it still gets all the runtime dependencies on the compile classpath. Is this somehow bound to the packaging type (which is aar in this case, not jar)?

[bigdaz]

It's exactly as you suspected @oehme: when the packaging is not a "known Jar packaging" then we don't create any variants for the module, which means that the compile/runtime separation is lost.

The non-jar packaging case is not one I considered when I put together this complicated sheet of dependency interactions. (Apologies, I can't seem to make that sheet public). We really need to think about the behaviour we want to make the default in 5.0.

[oehme]

Thanks Daz, I've opened a follow-up issue for 5.0

[Ethan1983]

I can confirm this is fixed from Gradle 5.0 for transitive aar (android) runtime dependency.