This message was deleted.

Constraint on

runtimeClasspath

should break a build so `apiElements`/`runtimeElements` should be broken too. I would think that it should be enough to prevent the sqlite impl propagation. I'm not sure if you should care at all about `compileClasspath`/`compileOnly`/`compileOnlyApi` in this case.

right now we're using the convention plugin approach, so I can add the constraint to my plugin and ensure it is present in every project of the build. Adding it to a platform also sounds like it would make sense

constraint on

implementation

should apply to

testImplementation

in the same project, at least for a platform applied to the project

with the constraint as indicated in my code snippet,

compileKotlin

will fail in the expected way, but

compileTestKotlin

will not

so similar case to the logging deps ,)

I've been using this as a reference. It suggests that testImpl should inherit from impl. I should be more clear though, that I'm in an Android project. Nevertheless, I think it follows this form

yeah, I use the same doc page as reference) but I'm not familiar with agp at all

a-ha, I was wrong, I wasn't using my constraint for Reasons. Tests do fail with the constraint as set up. At least that makes sense. I think I need to be more explicit and set it on the compile and runtime classpaths, since they should be independent of the test classpaths. Let's find out!

good clue

I do find the constraint docs a bit underwhelming, so if gradle dev saw this and chose to enlighten me, I would gladly accept that 🙂

same here ,)

If you add the constraint in all of your projects through a convention plugin,

implementation

is the best choice imo. You won’t win anything by using

api

. Using

api

would mean that the constraint would propagate, at compile time, as “transitive dependency” to all direct consumers of a project (that’s what apiElements is for). But you would still have to add it to all projects as there is nothing that would allow you to just add it to one project and then propagate it everywhere at compile time. Hence, I would stick with

implementation

.

thanks Jendrik! so, based on all that, and considering I'm talking about an android project and must not forbid this dependency for test purposes, do you agree I should use compileClasspath and/or runtimeClasspath?

You indeed need to put the constraint in a configuration that does not impact tests. I would recommend creating a dedicated configuration for this and have both

compileClasspath

and

runtimeClasspath

extend from it.

let's see if I understand the suggestion: as testImplementation inherits from implementation, any constraint you add to implementation affect tests. you can create another configuration that inherits from implementation (and compileOnly and runtime if needed) and apply the constraint

The motivation is to always separate bucket configuration - where you declare dependencies and constraints, cannot be consumer or resolved, from the other ones - the consumable or resolvable ones. It also helps thinking about variant attributes because declaring attributes on bucket configurations has no effect, since they are not carried over.

"noTestImplementation" or "implementationOnly" 😂

Well in this case, I would name it: forbiddenDependencies 😉

they are not forbidden for tests! (but I was just kidding anyway)

Right,

forbiddenRuntimeDependenciesThatAreAllowedInTest

😛

I must say the whole "test" idea is quite messy it's used as default unitTest, so if you create more test sourcesets/configurations you have to create your baseTest configuration, duplicate everything or use test as base for your integration tests. and then..most plugins assume everything is only in "test" without providing flexibility to have integrationTest for example. Even JaCoCo and test-fixtures are only configuring

test

IIRC

I'm at a bit of a loss for the moment. Despite putting the constraint on the debugTestRuntimeClasspath, my tests are failing because they can't resolve all the required dependencies. I don't understand why the test runtime classpath (debugUnitTestRuntimeClasspath) is seeing this constraint. It does not (directly) extend debugTestRuntimeClasspath... Printing the extendsFrom hierarchy confirms (I think) that my constraint shouldn't propagate

- debugUnitTestRuntimeClasspath extendsFrom:
  * testDebugRuntimeOnly
  * testDebugImplementation
  * testRuntimeOnly
  * testImplementation
  * debugUnitTestRuntimeOnly
    * testRuntimeOnly
    * testDebugRuntimeOnly
  * debugUnitTestImplementation
    * debugUnitTestApi
      * testApi
      * testDebugApi
    * testImplementation
    * testDebugImplementation

Maybe in the Android setup “unit test” actually dependents on the corresponding “main” variant(s) which brings in the constraint in your case? Where do you define it now? Is it only on

*Classpath

or also on

*Elements

? The later would make it propagate. A build scan (or running

dependencies

) should give more insights.

I followed Louis' suggestion and put it on a new configuration which I then had

debugRuntimeClasspath

extend from. The build scan was not super helpful; I still think these views have usability issues, and recall I used to teach people how to read this stuff. It clearly showed that the dependency was only present on

debugUnitTestRuntimeClasspath

, and then a whole bunch of paths to the constraint that I couldn't parse. Here's a snippet. I've also attached a screencap.

Dependency path 'register.common.addons:impl:unspecified' --> 'com.squareup.sqldelight:sqlite-driver:1.5.3'
   Constraint path 'register.common.addons:impl:unspecified' --> 'register.common.addons:impl:unspecified' (debugRuntimeElements) --> 'com.squareup.sqldelight:sqlite-driver:{reject all versions}' because of the following reason: <omitted for brevity>'
...

The "dependency path" in question is

testImplementation com.squareup.sqldelight:sqlite-driver:1.5.3

Does

(debugRuntimeElements)

imply that my test classpath inherits from the runtime classpath and therefore inherits the constraint as well? I could believe it, even though my code walking the

extendsFrom

relationship doesn't show it and it also conflicts with what I'd expect from the relationships described in the java-library plugin docs. I know those aren't exactly relevant for Android, but I was hoping (sigh) that Android was sane here

I think Jendrik is right there. It looks like a combination of two things: • Android uses a project dependency to get the main component in the test classpath • Android might define

debugRuntimeElements extendsFrom debugRuntimeClasspath

but that would be really annoying

I have this vague recollection that they might do something like that "manually". I'm pretty sure they don't use

extendsFrom

directly, or maybe it's in an afterEvaluate and it's an ordering issue that I can't see it. Well, I guess this idea is just dead in the water

Android is also doing some kind of “home made consistent resolution” between production code and test code classpathes. IIRC it creates constraints for the test classpathes based on the resolution result. (If that has not been changed by now.) This could also possibly cause this (rather strange) effect.