Dependencies of artifact producing projects with composite builds

We are trying to use composite builds in our code base to ease our development process with gradle version 8.7. When developing our code we have a project we will call “development” that has an includedBuild reference to many other projects that we will call “components”, “artifacts” and “deployment”. On our pipeline the “artifacts” projects will build the artifacts we produces and publish them to maven local for our deployment project to depend on like this:

val serverArtifacts by configurations.creating
dependencies {
serverArtifacts(“group:artifact:version@ear”)
serverArtifacts(“group:artifact:version@war”)
}

However during development we have all the components, artifacts and deployment projects as includedBuilds in the development project and want the artifacts to be built automatically when a specific deployment happens. To do this we have made custom plugins to handle each to of artifact that makes a provideArtifact task.

When we were running gradle 7.6.1 and lower we solved this problem by registering provideArtifact as the artifact for the configuration “default” and made sure it was the only consumable configuration in each artifact project. This is no longer possible after gradle 8.4 as consumability and resolvability of configurations is not allowed to be changed after creation of certain configurations.

Multiple of our artifact projects uses the ear and war plugins and as such when trying to depend on these projects we get variant conflicts. For the ear plugin we get deploy and earLib as conflicting configurations and neither of these contain the artifact that we want.

After some searching we found that we could clear the outgoing artifacts of the runtimeElements configuration when using the war plugin and register our artifact in this configuration and this does indeed work.

Working from this solution we have created our own configuration that has the same attributes as the runtimeElements configuration and this also give us the result we want, even if the values of the attributes makes little sense (such as org.gradle.libraryelements = jar). Now the issue is when runtimeElements already exists in an artifact project we get a variant conflict with our custom configuration and runtimeElements.

So my question is, how do I make a custom configuration that has the correct attributes such that the above dependency definitions will work and not interfere with the runtimeElements configuration?

Why don’t you simply register a custom attribute that you control? Then you can add outgoing configuration with that attribute where you add the artifacts you want to share and on the consumer side request that artifact.

Thank you for the reply. Had tried playing with attributes for days and now taking a new look at it I quickly find a solution… Thank you again :slight_smile:

1 Like