I didn't even bother trying something like this, it would surely just crash and burn in a modern Gradle project with configuration caching and everything, right?

Hm, the

project.group

switcheroo actually does work, but my Gradle experience teaches me that using hacks is an extremely bad idea

That's an important piece of information! I thought that I read about that limitation somewhere in the documentation within the last year, but I can't find it even in the Gradle 6.0 documentation

Is there a recommended way to create an included build programmatically, without writing out build files to the filesystem?

The

getUseGlobalDependencySubstitutionRules

appears to target this use case

Bingo, just gotta figure out how to use it

@Jendrik Johannes Is this feature expected to work within the current module, so that a project can obtain its own previously published jar file? The integration tests don't appear to test that case

Can you do it somehow without a composite build

In a single build you don't necessarily have substitutions for the subprojects. But I keep forgetting the details. I think if you don't add any substitution rules, projects and published versions can both be selected and the normal version conflict resolution (higher version wins) is used.

But if you don't turn that on, I think you can make it select a published version instead. But there is no strategy to "always select the published version".

Maybe it works with a strict version that points at the published version you want to select (?)

And I don't think an extra build can be created programmatically; it would require additional files, checked in to git

So if I can't do this through Gradle, I'll whip out an HTTP client and do it myself. I'd prefer to not have to do that

Imo it's a missing feature in Gradle and that would justify using such a workaround for me.

But first I'm going to look into this:

dependencies.create(
            group = "com.plexxi",
            name = "PlexxiCore",
            version = "${project.property(DbProps.REFERENCE_VERSION_PROP)}",
            ext = "war").apply {
            isForce = true
        }

Setting

isForce = true

is a fresh idea I haven't tried yet

isForce

has no effect, it's just another form of version syntax. I'm currently looking at using

ArtifactResolutionQuery

Looks like that API can only be used to obtain sources and stuff

OK, I've stepped through the code and concluded that this behavior is hardcoded into the graph resolution logic. @Jendrik Johannes, this is why setting strict versions, forcing versions, etc doesn't do anything. See in particular this commit, which specifically prevents "selection" from being deferred on the root module; it is performed as soon as the graph is constructed. Here, "selection" refers to the eviction of all other versions of the root module (see

ModuleResolveState#select

). This all happens early during the process of graph resolution, before artifact resolution can run, and it's a fixed behavior that is unaffected by any public APIs I'm aware of.

@Louis Jacomet Why this commit? It's tagged with

groovy-4-compile-problem

, but that's all I know

For anyone coming across this thread in the future: I caved and used the

project.group

hack. I figured the code in question was unlikely to change in a way that would suddenly break this approach, given its age, complexity, and overall design