From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

If it is only the *pom.xml* metadata that you want to modify, you can use the *pom { withXml { … } }* block to modify that directly after it has been generated. There you can replace the `+` with something else.
In this comment, there is an example for how to find the dependencies section and modify it:
<https://github.com/gradle/gradle/issues/3170#issuecomment-544248344>

Have you considered using open ranges (e.g. `[1.1,)`  instead of `1.1.+` ) which Maven also understands?

Are those syntaxes equivalent? I'm wondering why Gradle itself doesn't perform the conversion

Additionally, I noticed that the `withXml { ... }` block only runs after any POM metadata warnings have been emitted

I am not exactly sure with the differences between the notations. I think `[1.1, 1.2[`  would be equivalent to `1.1.+`  But maybe I miss some detail. I think these are slightly different approaches for how to look at versions. So they might not always (globally) be equivalent, but for most use cases they are.
<https://docs.gradle.org/current/userguide/single_versions.html>
<https://docs.gradle.org/current/userguide/rich_versions.html>

&gt;  POM metadata warnings have been emitted
Yes. You would need to turn off the corresponding warning.
<https://docs.gradle.org/current/userguide/publishing_gradle_module_metadata.html#disabling_metadata_compatibility_publication_warnings>

I think I would:
• If I really care about Maven (i.e. know that what I publish will be used with Maven), then I would switch to Maven-style ranges and not use `+` at all
• If I am just annoyed by the warning: Silence the warning and ignore what ends up in the POMs (they are not used).

Since Maven compatibility is largely theoretical for me at this point, I went with the second option. Thanks for all your advice!

Best practice is to not do it.
Or at the very least make it optional.
Plugins should not unconditionall add repositories.
Or you for example break company guidelines that enforce to use only internal repositories or break builds that use `FAIL_ON_PROJECT_REPO`.

Make sense. I think that’s why I can’t see this happens in public plugin.

It happens in some public plugins, but they are misbehavers in my opinion :slightly_smiling_face:

Would this not be a valid usecase for build convention plugins? Or perhaps commercial tools that have their own repository to pull in dependencies from.

Also can you elaborate on how can adding repositories(via a plugin) be made optional?

&gt; Would this not be a valid usecase for build convention plugins?
Sure, if you want to have it in some private plugin because it is the right thing to do for you in your builds, why not.
I'm talking about best practices and public plugins.
Many companies have the rule that you must only use internal repositories for various reasons,
for example reliability if the external service has an outage or internet access has an outage,
supply chain security by preventing to consume compromised external repositories,
and also by preventing cross-repository deployment attacks, ....

Additionally, I for example want even in my personal projects to know and control which repositories are used.
I usually declare repositories in the settings script using `pluginManagement` and `dependencyResolutionManagement` (this can of course also be done in a settings convention plugin)
and configure the mode to `FAIL_ON_PROJECT_REPOS`.
I expect this to also be done by the companies with the above mentioned rules.
Such builds will hard fail if any plugin tries to add a repository.

&gt; Or perhaps commercial tools that have their own repository to pull in dependencies from.
All that I said above.
This is bad practice, especially if it is hard-coded and not configurable.
The user of the plugin should always have the option to configure an own repository (mirror).

&gt; Also can you elaborate on how can adding repositories(via a plugin) be made optional?
Like any other logic too.
For example by configuring some extension.
Or by calling some method in some extension like `addDefaultRepository()` if the default is to not add it.
Many ways are thinkable.
Even a Gradle property would probably do.
Almost anything is better than hard-coded adding it automatically.
Or just don't add it and document that the user has to add it in his build.

Ah got it. Makes sense, I imagined a gradle api like the dependency substitution apis :slightly_smiling_face:
Yes this makes sense. Public plugins enforcing repositories would not be ideal.  Thank you for the detailed explanation!

Hmm in an example project it worked as expected. I guess I missed something in the large project that has this issue. However I solved it using a different approach which reduced the number of excludes I had to define. Now I use `dependencies { modules { module(…) { replacedBy (…) } }`

Iirc that's a Kotlin specific thing, so you should probably ask JetBrains.

Hi, looking for some help on this, please let me know if any additional details can help clarify the problem. Thanks

At first glance, the main difference would be that the platform dependency would have to be resolved from a repository, which puts a constraint on the projects using the plugin.
I wouldn't expect a big difference in performance though (the platform dependency would have to be resolved so that would likely be _slower_ than the alternative; AFAICT the platform once resolved would create the constraints the exact same way you would programmatically so I see no reason it would be faster, if that was your question)

thanks for that insight. That was basically my question.

What do you mean exactly by "build variant"?

I wanted to say build type, but it doesn’t matter, I want something like
```android.applicationVariants.all {  variant -&gt;
    if (variant.buildType.name == "release"){
        if ((libs.dependency.sdk.get() as String).contains("SNAPSHOT")) {
            throw new GradleException('Release builds should not contain SNAPSHOT builds of the Carealot SDK')
        }
    }
}```

Then → <#CJYS1DAP5|> maybe, because Gradle itself does not have a concept of "build type".

I think it is code Gradle (<https://docs.gradle.org/current/javadoc/org/gradle/nativeplatform/BuildType.html>). But it doesn’t matter for my question.

As you can see from the package, that build type has to do with building native software (C/C++).
It has nothing to do with Java programs, let alone Android apps.
So yes, it does matter for your question.

What you ask has nothing to do with Gradle itself, but is a specific of the Android Gradle plugin developed by Google.
Your chances to find someone able to answer in <#CJYS1DAP5|> is simply higher and it actually belongs there as it is Android related. :slightly_smiling_face:

If you use simple string notation (without special `!!` marker) it's just `require` (dependency or constraint doesn't matter) which pardon for the pun requires minimal version (or range) for dependency

I'm actually really confused by why the resolution engine would fail here. According to the <https://docs.gradle.org/current/userguide/rich_versions.html|docs>, a `strictly` constraint should override a previously set `requires`, and vice-versa. What am I missing?

It should override on the same MutableVersionConstraint object but in your case there are different constraints from different configurations

There is only one lockfile for all projects

that's not actually true, there's a lockfile per module. You have to define a task to resolve all dependencies in each module and run it with the `--write-locks` argument: <https://docs.gradle.org/current/userguide/dependency_locking.html#lock_all_configurations_in_one_build_execution>

Oh, ok, I thought they consolidated it into one file a while ago.
Must have misremembered.

a single file instead of a file per configuration :slightly_smiling_face:

it used to be dozens of files per module.. that wasn't the best

Ah, that was it. Sorry for the wrong info

Ok - found <https://docs.gradle.org/current/userguide/component_metadata_rules.html#making_variants_published_as_classified_jars_explicit|this> which solved it. Now I wonder how one would fix this from the publisher side :smile:

If you use `java.withSourcesJar()` - see: <https://docs.gradle.org/current/userguide/building_java_projects.html#sec:java_packaging> - instead of what you are doing now to create and publish the sources Jar, everything should be correct.

If you need something more custom, have a look at: <https://docs.gradle.org/current/userguide/publishing_customization.html>

Thanks Jendrik! I will go through the guide, learned a lot these days :slightly_smiling_face:

Not to generate one, but to update one: <https://github.com/micronaut-projects/micronaut-build/tree/master/src/main/java/io/micronaut/build/catalogs>

pretty dang close. I was just thinking maybe I could generate a lock file and then script up a transform on that to boot strap the catalog migration.

TY sir

Check also this one <https://github.com/littlerobots/version-catalog-update-plugin>

What do you mean by "identify"?
A BOM is just a POM with a `&lt;dependencyManagement&gt;` block.

I mean as like a bom artifact wont have jar file or similar in the repository, instead just a pom. So should just check for the availability of the pom without a jar to see if its a bom?

eg: <https://repo1.maven.org/maven2/net/kyori/adventure-bom/4.11.0/>

Yes, BOMs typically also do not have a jar.
But a POM without a jar is not necessarily a BOM.

BOMs often are also called `...-bom` but don't have to be

And a BOM could actually also be within another POM and be both

So there could even be a jar beside the POM that is also used as BOM

There is no reliable way to "identify" a BOM or non-BOM

I'm not sure I understood that :sweat_smile:

Does the pom file specify the file to be used?

For more context, I'm working on a runtime dependency manager (<https://github.com/slimjar/slimjar>). I initially just ignored any jar files it couldnt find considering it as bom, but that does not feel like the right way to go about this.

Ah, sorry, last message was in wrong chat

I do it, yes.
And there is "suffix" added.
The `gradle.plugin.` is the start of that artifacts coordinates.

It is an old convention where all artifacts published to plugin portal had to have a group that starts with `gradle.plugin.`

Actually the plugin in question has those coordinates until 3.2.1: <https://plugins.gradle.org/m2/gradle/plugin/com/google/cloud/tools/jib-gradle-plugin/>
And changed to the new coordinates thereafter: <https://plugins.gradle.org/m2/com/google/cloud/tools/jib-gradle-plugin/>

So maybe you have some manual id to artifact mapping where you still have the old coordinates but updated the version or something like that.

Actually you should usually not have that manual mapping, but just depend on the marker artifacts that translate plugin id to code artifact

I have that "manual mapping" because that's the only way to do it with convention plugins / platforms, as far as I know?

the project structure is based on <https://docs.gradle.org/current/userguide/structuring_software_products.html>, with `build-logic` and `platforms`

Ah, so you have it in the dependencies of your convention plugin build.
But also there, you can simply use the plugin marker artifact. `&lt;plugin-id&gt;:&lt;plugin-id&gt;.gradle.plugin:&lt;plugin-version&gt;`

interesting, I didn't realize that was an option, but looking back at the sample project that can be downloaded on <https://docs.gradle.org/current/userguide/structuring_software_products.html> it's done that way there as well... I must have glanced over that back when I was looking at that.

that also clears up some confusion around why I always needed to look up these coordinates from the "legacy" sections on e.g. <https://plugins.gradle.org/plugin/com.google.cloud.tools.jib> :slightly_smiling_face: thanks!

seems like it'd be nice if the Gradle DSL had a built-in function to build that marker artifact coordinate from the plugin id, considering it's a bit redundant. but I just saw you had a similar idea a while ago already :smile: <https://github.com/gradle/gradle/issues/9282#issuecomment-490219792>

Hello! I’m trying to substitute a dependency in my settings file for an included build. I’m using the approach described <https://docs.gradle.org/current/userguide/resolution_rules.html#sec:substitution_with_attributes|here> , see Example 9. But I’m struggling to define the attribute as there is no `objects.named` in settings as far as I can see. And if I implemented the `Named` with anonymous class or even top level object, I get:

&gt;  org.gradle.internal.snapshot.impl.IsolationException: Could not isolate value Settings_gradle$2$1$1$1$1@4c506b93 of type Settings_gradle.....
How can I achieve this?

AFAIK, Gradle uses a "simple" URLClassLoader, so no modules (and Gradle starts itself with a classpath, not module path, in case that matters).

That’s correct. You can’t load Jars as Modules in Gradle plugins. So even if Nashorn is a JPMS module, the module information is ignored. But I think it should also work in that environment. ServiceLoader existed before JPMS already and can be used also in a classpath environment (but I am no expert on that topic).

But AFAIK ServiceLoader only takes into account META-INF/services in a classpath environment, not module-info, and Nashorn only provides the module-info definition of the service.

OK, so this means probably the URLClassLoader respects the module-info definition in a JDK9+ environment to handle the ServiceLoader correctly. Will check how this is implemented in Spotless.

Spotless uses a custom class loader derived from URLClassLoader to load the formatting features.

I don't know the answer, but I would search for "version cannot contain" in Gradle source code.

So this error probably comes from <https://github.com/gradle/gradle/blob/9206396fd45065a0fd2a2d5398d5cf9345375521/subprojects/publish/src/main/java/org/gradle/api/publish/internal/PublicationFieldValidator.java#L49-L75|PublicationFieldValidator>. And `validInFileName()`  for `version` is called in <https://github.com/gradle/gradle/blob/9206396fd45065a0fd2a2d5398d5cf9345375521/subprojects/maven/src/main/java/org/gradle/api/publish/maven/internal/publisher/ValidatingMavenPublisher.java#L63-L65|ValidatingMavenPublisher>.

I might be wrong, but I _think_ this won’t work conceptually. The resolution is happening unfiltered and produces the ’ResolvedComponentResult’s, which point at the components, but not directly at the artifacts behind them. The artifacts are retrieved in the next step (if needed), where an Artifact View possibly intervenes/filters/transforms.

If this is correct, you need to do the filtering inside the task. Which is fine from a performance perspective etc., because the resolution result (which is not the artifacts) is constructed in any case.

hmmm ok, thanks for the perspective. I'll give it a try (filtering inside the task action)

I'm having trouble making this work. I'm following the <https://docs.gradle.org/7.5/userguide/more_about_tasks.html#sec:task_input_using_dependency_resolution_results|Authoring Tasks guide> as well as the <https://docs.gradle.org/7.5/samples/sample_tasks_with_dependency_resolution_result_inputs.html|sample> and I'm getting this error:
```Caused by: org.gradle.internal.execution.fingerprint.InputFingerprinter$InputFingerprintingException: Cannot fingerprint input property 'artifactIds': value '[junit-4.12.jar (junit:junit:4.12), hamcrest-core-1.3.jar ... 

cannot be serialized.
...
Caused by: java.lang.ClassCastException: class org.gradle.internal.component.local.model.ComponentFileArtifactIdentifier cannot be cast to class org.gradle.internal.component.external.model.ModuleComponentFileArtifactIdentifier (org.gradle.internal.component.local.model.ComponentFileArtifactIdentifier and org.gradle.internal.component.external.model.ModuleComponentFileArtifactIdentifier are in unnamed module of loader org.gradle.initialization.MixInLegacyTypesClassLoader @638ef7ed)
	at org.gradle.api.internal.artifacts.metadata.ModuleComponentFileArtifactIdentifierSerializer.write(ModuleComponentFileArtifactIdentifierSerializer.java:26)
	at org.gradle.internal.snapshot.impl.AbstractValueProcessor.gradleSerialization(AbstractValueProcessor.java:160)
	... 68 more```
where my code looks like this:
```@get:Input
abstract val artifactIds: ListProperty&lt;ComponentArtifactIdentifier&gt;

internal fun configureTask(
  compileClasspath: Configuration,
  runtimeClasspath: Configuration
) {
  val extractor = IdExtractor()
  artifactIds.addAll(compileClasspath.externalArtifactsFor("jar").resolvedArtifacts.map(extractor))
  artifactIds.addAll(runtimeClasspath.externalArtifactsFor("jar").resolvedArtifacts.map(extractor))
}

internal fun Configuration.externalArtifactsFor(attrValue: String): ArtifactCollection = externalArtifactViewFor(attrValue).artifacts

private fun Configuration.externalArtifactViewFor(attrValue: String): ArtifactView = incoming.artifactView {
  attributes.attribute(Attribute.of("artifactType", String::class.java), attrValue)
  lenient(true)
  componentFilter { id -&gt; id is ModuleComponentIdentifier }
}

private class IdExtractor : Transformer&lt;List&lt;ComponentArtifactIdentifier&gt;, Collection&lt;ResolvedArtifactResult&gt;&gt; {
  override fun transform(artifacts: Collection&lt;ResolvedArtifactResult&gt;): List&lt;ComponentArtifactIdentifier&gt; {
    return artifacts.stream().map(ResolvedArtifactResult::getId).collect(Collectors.toList())
  }
}```
Note that I must use an `ArtifactView`, because this is an Android project, and I have to tell Gradle which `artifactType` I'm querying for or it cannot resolve the configuration. Not using an artifactView simply leads to a different error.

<@UES7RHBDZ> do you have a complete failing example? I tried to reproduce with the following build script but I was unable to:

```plugins {
    `java-library`
}

abstract class PrintIds : DefaultTask() {

    @get:Input
    abstract val artifactIds: ListProperty&lt;ComponentArtifactIdentifier&gt;

    @TaskAction
    fun printIds() {
        artifactIds.orNull?.forEach {
            println(it)
        }
    }

    internal fun configureTask(
        compileClasspath: Configuration,
        runtimeClasspath: Configuration
    ) {
        val extractor = IdExtractor()
        artifactIds.addAll(compileClasspath.externalArtifactsFor("jar").resolvedArtifacts.map(extractor))
        artifactIds.addAll(runtimeClasspath.externalArtifactsFor("jar").resolvedArtifacts.map(extractor))
    }

    internal fun Configuration.externalArtifactsFor(attrValue: String): ArtifactCollection =
        externalArtifactViewFor(attrValue).artifacts

    private fun Configuration.externalArtifactViewFor(attrValue: String): ArtifactView = incoming.artifactView {
        attributes.attribute(Attribute.of("artifactType", String::class.java), attrValue)
        lenient(true)
        componentFilter { id -&gt; id is ModuleComponentIdentifier }
    }

    private class IdExtractor : Transformer&lt;List&lt;ComponentArtifactIdentifier&gt;, Collection&lt;ResolvedArtifactResult&gt;&gt; {
        override fun transform(artifacts: Collection&lt;ResolvedArtifactResult&gt;): List&lt;ComponentArtifactIdentifier&gt; {
            return artifacts.map(ResolvedArtifactResult::getId)
        }
    }
}

dependencies {
    implementation("junit:junit:4.12")
}

repositories {
    mavenCentral()
}


tasks {
    register&lt;PrintIds&gt;("printIds") {
        configureTask(
            configurations.compileClasspath.get(),
            configurations.runtimeClasspath.get()
        )
    }
}```

<@UAWC3KVM4> thanks for taking a look. Here's a <https://github.com/autonomousapps/dependency-analysis-android-gradle-plugin/pull/747|draft PR> with the changes. You can repro the failure with
```./gradlew :funcTest --tests DuplicateDependencyVersionsSpec```
and for good measure, here's a <https://scans.gradle.com/s/gha7f6srbe2tu/tests/:functionalTest/com.autonomousapps.android.DuplicateDependencyVersionsSpec/can%20show%20duplicate%20dependency%20versions%20(Gradle%207.5%20AGP%207.4.0-alpha07)?top-execution=1|build scan> showing the test failure

<@UAWC3KVM4> hate to bother you, is there anything else I can provide to help get to the bottom of this?

Hey <@UES7RHBDZ>, I was about to give you an update. I was able to reproduce the issue and come up with a fix.

I’ll need you to test a nightly once it’s out.

thanks! That's exciting :slightly_smiling_face:

and no problem

Hey <@UES7RHBDZ>, CI had some hiccups producing the nightly but it’s available now, `7.6-branch-bamboo_cc_release_ComponentArtifactIdentifier_ListProperty-20220914130118+0000` has the candidate fix.

<@UAWC3KVM4> I have confirmed that the candidate fixes my test!

<@UAWC3KVM4> does that mean this change will be in Gradle 7.6? Any eta on that release?

this works when B has `api(lib)`but not with `implementation(lib)`

```configurations.compileClasspath {
    resolutionStrategy {
        eachDependency {
            if (requested.group == "io.ktor") {
                throw RuntimeException("KTOR FOUND!")
            }
        }
    }
}```

hum..I have to add in my case project B is a kotlin multiplatform project...and I don't see the dependency in the scan

With `implementation(lib)` in B, then the `compileClasspath` in A won't have `lib` in it (that's the point of `api` vs `implementation`). Maybe just check `runtimeClasspath` instead?

BTW, how about a dependency constraint with `version { rejectAll() }`? (wouldn't work for a groupId only, requires an artifactId too)

no luck because it's not really there...I think it's an issue of kotlin MPP -&gt; kotlin jvm

That works...

```configurations.default {
    resolutionStrategy {
        eachDependency {
            if (requested.group == "io.ktor") {
                throw RuntimeException("KTOR FOUND!")
            }
        }
    }
    resolve()
}```
but I'm terrified

ok...you where right, runtimeClasspath is it, but I need to resolve it and `assemble` is not resolving it

Maybe using "resolution consistency" with `useRuntimeClasspathVersions()` would resolve it whenever the compile classpath needs to be resolved; but that kind of resolution consistency might not be what you want…

test task resolves it (and publishing tasks) so it's fine, I dropped the `resolve()`

Alternatively, add your `project(B)` dependency in such a way that its `runtimeElements` variant is always used (rather than the `apiElements`  variant)

right now it's simply:
```dependencies {
    implementation(project("B"))```

Out of memory, something like:
```implementation(project("B")) {
    attributes {
        attribute(Usage.USAGE_ATTRIBUTE, objects.named(Usage.JAVA_RUNTIME))
    }
}```
(no idea if that would actually work though!)

hehehe, I'll try to understand what it does..

I think the current solution is good enough, and the issue with the approach you suggested is that it needs to be applied to all dependencies.

anyway, thanks a lot for helping!

you can get the ID and apply it from `libs.plugins.detekt`

not remember exactly, something like `libs.plugins.detekt.get().id` or something so

I have found this
```plugin(libs.plugins.detekt.get().pluginId)```
but build is crashing
```org.gradle.internal.exceptions.LocationAwareException: Build file '/Users/igorwojda/StudioProjects/android-showcase/build.gradle.kts' line: 20
Extension with name 'libs' does not exist. Currently registered extension names: [ext]
	at org.gradle.kotlin.dsl.execution.InterpreterKt$locationAwareExceptionFor$2.invoke(Interpreter.kt:601)
...```
:thinking_face:

```subprojects {
    apply(plugin = libs.plugins.detekt.get().pluginId) 
}```

Actually, using `subprojects { ... }` is a smell anyway and you should avoid it but instead use convention plugins.

Loop over `getLibraryAliases()`, call `findLibrary()` for each of them, then filter the result based on `getModule().getGroup()`? (assuming you meant a groupId here; I have no idea what this `projects.gradleExtensionsSubjects` and its properties are though, so maybe I completely misunderstood your question)

Ah, nevermind, you're talking about type-safe project accessors, right? (not much to do with version catalogs actually) then I think you can do `projects.gradleExtensionsSubprojects.dependencyProject.subprojects`

that could break project isolation right?

No, at least it should not. Gradle knows all projects and you only want to know which other projects exist, you do not want to reach into their respective builds and access anything.

That's probably more a question for JetBrains and / or their YouTrack. Usually a reload of the Gradle project should be sufficient I'd say.

I agree. I saw some open and fixed tickets on their YouTrack. I was wondering what everyone's experiences were on this.  Auto complete not consistently working makes devx way worse than not having version catalogs at all.

Well, that I personally do not agree. :-)

I acknowledge that, I rushed to an opinion. Nevertheless, without the auto complete, devs will need to look up somewhere else to figure out the libs.* nested path.  The discoverability will be impaired..

Of course. Every time AC does not work is unfortunate of course. But just that it sometimes does not work doesn't make it worse than before. The times it works (98.7 % for me roughly estimated) it is much better.

my error looks like:
```Cannot select module with conflict on capability 'com.grubhub.roux5:roux-bom-derived-platform:5.26.5' also provided by [com.grubhub.roux5:roux-bom:5.26.5(platform-runtime), com.grubhub.roux5:roux-bom:5.26.5(enforced-platform-runtime)]```

A BOM is not meant for version management, it is meant for version alignment. Use a version catalog to manage your versions, as this has no effect on the publishing and it does not interfere with the alignment.

```[versions]
dependency = '1.2.3'

[libraries]
org-group-module-a = { module = 'org.group:module-a', version.ref = 'dependency' }
org-group-module-b = { module = 'org.group:module-b', version.ref = 'dependency' }```
```dependencies {
    api(libs.org.group.module.a)
    api(libs.org.group.module.b)
}```
If you actually want to expose the BOM (which sometimes sadly is necessary because too many vendors do not know how to work correctly with BOMs) then `api(platform("..."))` is the way to go, even in a library.

See also <https://docs.gradle.org/current/userguide/platforms.html#sub:platforms-vs-catalog> which is about exactly the differences (and explains all the rest too).

actually, what I was trying to do works. The person who reported the issue had their project on gradle 5 still, so I just had to have them upgrade to gradle 6+

by " manage" i mean align as well as allow dependencies to be declared without a version since the BOM will auto-align it.

As long as you use `platform` and not `enforcedPlatform` it should work, yes. Gradle should also warn or even refuse it publish things with an `enforcedPlatform`. This really is only for edge cases.

I would still recommend to strictly use version catalogs for managing versions and BOMs for alignment, and to not mix them. In a perfect world nobody would ever have to have a BOM in any build script, unless it is their own.

&gt; In a perfect world nobody would ever have to have a BOM in any build script, unless it is their <http://own.In|own.In> a perfect world nobody would ever have to have a BOM in any build script, unless it is their own.
hi, I find this discussion very interesting as I am investigating how to replace spring's dependency management plugin with more native gradle constructs. Am I correct to assume that such a case is one of the edge case where depending on a bom is inevitable ? I have been unable to find a version catalog published by the spring boot project but I may have missed things

Spring suffers from the problem that the dependencies they depend on are broken in many ways. This forces them to publish a BOM for third-party libraries. Hence, yes, this is such a special case.

You can replace the Spring dependency management with a simple `implementation(platform(SpringBootPlugin.BOM_COORDINATES))` (and if you need it in other configurations add it there too, e.g. `kapt(platform(SpringBootPlugin.BOM_COORDINATES))`).

The only reason why the Spring team still provides the plugin is for users to easily change versions of broken transitive dependencies without knowing the ins and outs of how Gradle resolution works. Well, this applies to newer Gradle versions. Old Gradle versions lacked a lot of features and thus forced Spring to provide the plugin, but those days are gone.

See also <https://github.com/spring-projects/spring-boot/issues/29588#issuecomment-1028861122>

thanks, that confirms part of my research. Of course our situation is slightly more involved since the build is a few years old and overrides multiple dependency versions provided by spring for various reasons. This was done by creating our own bom which declares spring's bom as its parent pom and overrides various properties there.
For now we  `import` that bom using spring's  dependency plugin then override the dependencies that didn't resolve to the correct versions using `dependencies` entries.
I must say I am unsure what a proper idiomatic gradle override would look like and how version catalogs and platforms fit in there.
I am trying to search this slack, as well as the forums and internet at large but without luck until now

This <https://docs.gradle.org/current/userguide/resolution_rules.html> should actually answer all your questions. The reason why you still need the Spring BOM even with your customization is because it has exclude rules and you don't want to recreate those.

so a version catalog that contains all the overridden versions  and a resolution strategy to enforce it over what spring suggests

You could also look into <https://github.com/nebula-plugins/gradle-resolution-rules-plugin/wiki/Consuming-Rules> which provides a simple way to set up and share many resolution rules, going way beyond what you can build with version catalogs. However, it also has certain limitations (e.g. <https://github.com/nebula-plugins/gradle-resolution-rules-plugin/issues/97>) that Gradle itself does not have. That said, it's still trivial to use, and the default rules it provides are a gold mine. :wink:

I have noted the reference, but I think I will try to stick to gradle native

<@U02162U7WCX> do you want the consumers of the library to be aware of the `bom:1`  at all? If not, you could exclude it from the published .pom and .module files by using a custom Gradle configuration + resolved versions in publications. Here's a sample project which demonstrates that - <https://github.com/jjohannes/gradle-demos/tree/main/internal-platform>

&gt; The only reason why the Spring team still provides the plugin is for users to easily change versions of broken transitive dependencies without knowing the ins and outs of how Gradle resolution works. Well, this applies to newer Gradle versions. Old Gradle versions lacked a lot of features and thus forced Spring to provide the plugin, but those days are gone.
&gt; 
That is not actually true <@U01A244DYUF>. Don't get me wrong, I also prefer and advice to use Gradle native functionality if it is just about using a BOM. 
But the plugin has additional unique functionality people might want to use like porting over imho broken-by-design features from Maven to the Gradle world and other things. So the plugin is not only maintained because of the version overwrites. ;-)

I just quoted the maintainer from the ticket I linked.

To be honest, I cannot find the origin of that quote in the ticket, not even semantically. He states that the two "key capabilities" are version management and version overwrites, but that's all.

I also thought in the past that these are the only features and the plugin is obsolete with platform support, but was told otherwise. Just have a look at the documentation and you see that it has some more features which simply are not the "key capabilities".

Sorry, too many issues on this in the Spring issue tracker and my brain history. See <https://github.com/spring-projects/spring-boot/issues/21723> and also <https://github.com/spring-projects/spring-boot/issues/21570> as well as <https://github.com/spring-gradle-plugins/dependency-management-plugin/issues/280> and probably _x_ other issues I cannot find right now. I'm not a Spring maintainer but <@UAC5H70PK> is in this Slack and he is also the one who commented on these issues, and wrote the following in the Spring Boot reference docs (see <https://github.com/spring-projects/spring-boot/commit/d2926e02222f942948637bd5bb6972379eb094c8>):

```To manage dependencies in your Spring Boot application, you can either apply the {dependency-management-plugin}[`io.spring.dependency-management`] plugin or, if you are using Gradle 6 or later, use Gradle's native bom support.
The primary benefit of the former is that it offers property-based customization of managed versions, while using the latter will likely result in faster builds.```
I know that Gradle did not support various BOM features Maven did (e.g. exclusions), and I know that Gradle resolves dependencies differently than Maven and that some people tried to bend Gradle to resolve them the same way (not sure if this plugin did). However, Maven resolving is broken and Gradle does support all BOM features by now (well, during consumption; it is not possible for us to use all BOM features with the `platform` plugin yet <https://github.com/gradle/gradle/issues/12214>).

Anyway, unless you have some credible sources I stick with what I've learned over the past years and do not use the dependency management plugin in any of my projects. So far I faired well with this and do not fear recommending anyone to do the same.

Thanks for adding me to the thread, <@U01A244DYUF>.

&gt; So the plugin is not only maintained because of the version overwrites. :wink:
<@URQ797WRW> I'm afraid you're mistaken. That is the only reason that the plugin is still maintained. Support for Maven-style exclusion semantics <https://github.com/spring-gradle-plugins/dependency-management-plugin/issues/331|will be removed in the future> . In fact, it would have already happened if we'd had the bandwidth for it. I'd strongly encourage you to look at using Gradle's built-in platform support and find an alternative way of dealing with the lack of property-based version overrides.

<@UAC5H70PK> thanks for the clarification. Quick question, is there a reason why not all Spring Boot &amp; Cloud packages reference the Spring Boot or Cloud BOM of their release? This would tremendously simplify things for everyone. Especially the Cloud releases are complicated because of the weird versioning scheme with code names.

Sorry, I'm not sure I understand the question. Also, describing something as "terrible" isn't a great way to start a constructive discussion.

I’m really sorry, I guess I was typing faster than thinking. I corrected that and hope you can forgive me.

The main purpose of a BOM is to align versions in a dependency tree. Most end users care about it because it allows them to leave out versions, but that it actually an added bonus and not its most important feature. Suppose we have a BOM called `spring:platform` and two modules called `spring:a` and `spring:b`. All of them are properly released together with a matching version (just like in the Spring case). The `spring:platform:1` references `spring:a:1`  and `spring:b:1`; the `spring:platform:1` references `spring:a:1`  and `spring:b:1`; and so forth. Now if I do…
```dependencies {
  implementation("spring:a:1")
  implementation("spring:b:2")
}```
…things are not going to be aligned, since I did not manually add the BOM. Suppose now that both modules reference the respective BOM and we would get auto-alignment (not only in Gradle, but also in Maven).

I see a lot of projects where people don’t know what BOMs are and they keep on writing the versions they need manually everywhere. Having all the modules include their BOM would solve possible issues they might encounter. This is especially true if they inherit those dependencies through transitives.

I also see most projects not having BOMs, and those who do are not actually referencing their own BOMs in their dependencies. Ultimately reducing the value the BOM can actually provide.

A project I know of where this is done correctly is Jackson, see: <https://github.com/FasterXML/jackson-annotations/blob/082ee2812f0a7019516181947e591d8ed624425a/pom.xml#L129-L137>

&gt; Suppose now that both modules reference the respective BOM and we would get auto-alignment (not only in Gradle, but also in Maven).
I don't believe that's the case. Assuming Maven pom metadata here as that's the lowest common denominator, I don't believe a bom that's imported or used as a parent in those modules will affect the dependency graph of a consuming project.

For example, Maven will just take the version that's nearest to the root of the graph so you'll end up with `spring:a:1` and `spring:b:2` as the versions declared in the pom are only one edge from the root.

I’m certain you know better how Maven works than I do. I avoid it by all means and haven’t had to use it in the past two years once. It definitely works like that in Gradle. :slightly_smiling_face:

TIL. I hadn't realised that Gradle's module metadata did that. That's quite handy.

We could consider it for Boot if we introduced a separate `spring-boot-bom` that was a true bill of materials for Boot's own modules. I don't think Boot's modules should reference `spring-boot-dependencies` as that's too opinionated and we intentionally allow people to choose not to use Boot's management of third-party dependencies.

I for one would love a spring boot standalone BOM. Right now I build my own so that I can align boot versions without effecting other transitives. (I use the spring BOM as well)

Please open an issue and we'll take a look. I can't guarantee that it'll make it into 3.0, but I think it would be a useful addition.

Makes perfect sense to use a dedicated Spring Boot only BOM (Cloud afaik already has one) and to not use the dependencies BOM. Although, no harm is done by using it. The versions from the BOM are only a recommendation to Gradle. So if the Spring BOM says Kotlin 1.6.10 and the user uses 1.7.10 it would resolve to 1.7.10 (although resolution would be inconsistent because JetBrains does not reference their own BOM either). In any event, I think this knowledge needs to be spread wider. I’ll open an issue.

Attached is a screenshot of Gradle doing exactly what I explained.

<https://github.com/spring-projects/spring-boot/issues/32412>

&gt; <@URQ797WRW> I'm afraid you're mistaken. That is the only reason that the plugin is still maintained
No need to <@UAC5H70PK>, I'm happy I was outdated.
That was the info I was given by some Spring guy (don't remember who it was) when I said similar things as Fleshgrinder here.
So things probably have changed to the better in the meantime. :slightly_smiling_face:

&gt; Anyway, unless you have some credible sources I stick with what I've learned over the past years and do not use the dependency management plugin in any of my projects. So far I faired well with this and do not fear recommending anyone to do the same.
<@U01A244DYUF> as said before, I would never recommend anything else and I'm also never using the dep-management plugin and always advise to use the built-in support when I see it used.
I just said that the dep-management is not the only functionality of the plugin that someone might want to use as that was what I was told in the past by some Spring guy when I said the plugin is useless with the added native BOM support in Gradle. :-)

Hey everyone :wave: . Can I funnel an artifact view into a particular configuration? :thinking_face:

I have my dependencies publishing two artifacts, one a normal jar and another a special metadata file. If I specify the dependency in the `implementation` configuration, I want to set up my build to automatically filter which dependencies inside `implementation` have that extra metadata file published and pass the metadatas to my special `myMetadatas`  configuration.

Sounds like you want the third-parties to apply a plugin that publishes a new variant with a some custom attributes defined by your plugin… then you have a resolvable configuration in your consuming project that requests those attributes.

yeah exactly. within my own build logic, how can I configure my build that for any dependency added in `implementation` with gav `a:b:c` , if a variant at same coordinates with _my attributes_ exist, add that variant *automatically* as a dependency to my custom configuration `myMetadata` for example

you create a resolvable configuration that extends implementation and requires that attribute

you may then need a artifact view or a lenient configuration to resolve it since you know some artifacts will not have a matching variant

I find `JvmPluginServices` to be useful for this:
```Configuration myMetadata = jvmPluginServices.createResolvableConfiguration("myMetadata", builder -&gt; builder
                    .extendsFrom(implementation).requiresAttributes(attrs-&gt; attrs...))```

Okay, now for level 2 difficulty, what if, the custom configuration that I want to funnel that variant into is not created by me :sweat_smile: but another plugin and per-adventure it doesnt extend implementation :sweat_smile:

Looks like this may do it:
```configurations {
    testImplementation.exclude group: 'ch.qos.logback'
}```

Try to create instead of named. I'd guess it works.

Yeah, I have used `create` and it works, but looks like a bug to me

Well, the default is just created if it was not created by the build already.
Could well be intentional.
But feel free to open a GitHub issue. :slightly_smiling_face:

Isn't default created only when `gradle/libs.versions.toml` file exists? IIRC when it exists create will fail.
You could use `maybeCreate("libs").configure { ... }`.

Obviously it does not fail.
He has that file and just wants to override one version of it for whatever reason.

That is the thing it is weird for me, create should fail and named work, but it is the contrary 

Ahh, I misunderstood. I thought gradle did create/maybeCreate before the settings script is executed but it seems opposite is true if manual create works. With such an ordering I'm not sure if you can truly override version since gradle would override your version from toml later.
Of course you can rename a toml file, create libs catalog and import the toml file with from(files(..)) and then override the version.

That the from is evaluated later does not mean the version from the toml wins. I'd still expect it to work.

Yeah, I would too ,) But need to experiment or look at the code to be sure

Yeah, it works, I tested it a few hours ago. The use case is a plugin testing itself with the latest changes 

Just to be sure I understand:
you use `create` for your use case
but do you have to also explicitly do the `from` then?
If not, please file an issue as it makes no sense.

If you have to do the `from` yourself, then you can see the default `libs` as being a convention, and any change you want to make to it forces your to be fully explicit.

You have to use `create` to be able to access / modify even the default `libs`.
If you use `create` and also add a `from` you get an exception that you must not call `from` multiple times even if you only called it once and even if you just specify the convention file again (I already opened an issue for this in the past).

<https://github.com/gradle/gradle/issues/21328>

I think the intuitive things is that libs should be created automatically so I should be able to get it instead of “creating” it

ok, I got a hint with: `outgoingVariants` task

Still think I would enjoy having some documentation about attributes (not saying it doesn't exist, just didn't found it)

<https://docs.gradle.org/current/userguide/variant_model.html> :tada:

But I see in artifacts only shows the project jar, while it should have all the runtime dependencies, I guess dependencies are not resolved in that task

Fwiw, did you see <https://docs.gradle.org/current/userguide/cross_project_publications.html> ?

If you mean with "in artifacts" in the output of `outgoingVariants`, then yes, it only shows the artifacts as the name suggests, not the dependencies.

And yes, if you select the same consumable configuration using the attributes it should result in the same result, yes. You can even set the attributes on the dependency individually if you don't want those attributes for all dependencies in that `someClasspath` configuration.

<@UDC9Q9RD0> is where I started, but I think I missed some details

And regarding the attributes, each ecosystem or plugin should describe the attributes defined.
Here you find the built-in attributes: <https://docs.gradle.org/current/userguide/variant_attributes.html#sec:standard_attributes>

The Kotlin one should then be documented by the Kotlin plugin documentation.

And you can always check using `outgoingVariants` which are actually present.

<@URQ797WRW> I expected apiElements and runtimeElements to show different artifacts in the outgoingVariants report, that's what confused me even more

and about:
&gt; What would be the best solution?
I guess attributes has the advantage that if we use for example Kotlin multiplatform and they have another name for the configuration it won't matter..we only require a configuration with those attributes.

Small advantage I guess (over using a hardcoded configuration name)

&gt; <@URQ797WRW> I expected apiElements and runtimeElements to show different artifacts in the outgoingVariants report, that's what confused me even more
Why would you expect different artifacts?
They should be the same artifacts, but have different dependencies.
That's the result of `api` vs. `implementation` vs. `runtimeOnly`.

&gt; Small advantage I guess (over using a hardcoded configuration name)
Well, using configuration name is the old way, using attributes is the new way.
Using configuration name also only works for inter-project dependencies within one build, attributes work also with published libraries (for published variants only of course).

Dependencies get transformed into artifacts for the consumer

If that was regarding my statements about artifacts above, sure.
But that's a consumer-side thing.
`outgoingVariants` is a producer-side thing.
And from the producer PoV he has one artifact and X dependencies on that variant. :slightly_smiling_face:

I didn't think on that. I think I connected all the dots now. Thanks!

for producer..lt's "simple":

```val jars by configurations.creating {
    isCanBeConsumed = true
    isCanBeResolved = false
    attributes {
        attribute(Usage.USAGE_ATTRIBUTE, objects.named(Usage.JAVA_RUNTIME))
        attribute(org.jetbrains.kotlin.gradle.plugin.KotlinPlatformType.attribute, org.jetbrains.kotlin.gradle.plugin.KotlinPlatformType.jvm)
        attribute(LibraryElements.LIBRARY_ELEMENTS_ATTRIBUTE, objects.named("produced-jar"))
    }
}

artifacts {
  add(jars.name, tasks.jar)
}```


I assume for consumer it's:

```val consumerJars: Configuration by configurations.creating {
    isCanBeConsumed = false
    isCanBeResolved = true
    attributes {
        attribute(Usage.USAGE_ATTRIBUTE, objects.named(Usage.JAVA_RUNTIME))
        attribute(org.jetbrains.kotlin.gradle.plugin.KotlinPlatformType.attribute, org.jetbrains.kotlin.gradle.plugin.KotlinPlatformType.jvm)
        attribute(LibraryElements.LIBRARY_ELEMENTS_ATTRIBUTE, objects.named("produced-jar"))
    }
}
dependencies {
  consumerJars(project("middle))
}```


just adding dependencies...my issues i that I missed adding the jar artifact in middle... sorry

Basically, I get the message:
```Could not determine the dependencies of task ':sub:resolveTransform'.
&gt; Could not resolve all task dependencies for configuration ':sub:resolvedTransform'.
   &gt; Could not resolve project :.
     Required by:
         project :sub
      &gt; No matching variant of project : was found. The consumer was configured to find attribute 'my-special-attribute' with value 'target' but:
          - Variant 'outConf' capability sample:emptygradle:1.0:
              - Incompatible because this component declares attribute 'my-special-attribute' with value 'something' and the consumer needed attribute 'my-special-attribute' with value 'target'```
The result of calling outgoingVariants on the dependent project is:
```&gt; Task :outgoingVariants
--------------------------------------------------
Variant outConf
--------------------------------------------------

Capabilities
    - sample:emptygradle:1.0 (default capability)
Attributes
    - my-special-attribute = something
Artifacts
    - build/archive/output.zip (artifactType = zip)```


And the registration is called with:
```val specialAttribute = Attribute.of("my-special-attribute", Named::class.java)

dependencies {
    attributesSchema {
        attribute(specialAttribute)
    }
    registerTransform(ArchiveUnzipTransform::class.java) {
        from.attribute(specialAttribute, objects.named("something"))
        to.attribute(specialAttribute, objects.named("target"))
    }
}```


Yes this is always tricky. The API isn’t clean here imo.

What you need to be aware of is that there are:
1. Attributes on *Variants* (Configurations) that are used to match the Variants (Configurations) in the 1st phase of dependency resolution
2. Attributes on *Artifacts* which are used to access artifacts in the 2nd phase of dependency resolution
But both use the same `Attribute` interface. The same attribute can be used in both places, but it is really hard to get it to a certain behaviour. What you are seeing now is the first phase of resolution failing, because the variants cannot be matched. The two attribute values are not compatible. At this point, transforms are not even considered yet (because they only work on the artifacts later).

This behavior is not intuitive and I stumble over this every time I attempt to use transforms.


The best setup is (if it is sufficient for your use case) to not use a second resolvable configuration. Instead, use an ArtifactView, when accessing the artifacts (2nd phase of resolution). Then the different attribute values only play a role for the artifact retrieval (after the variant selection has already been performed).

In your sample, you can remove the ~resolvedTransform~ configuration. And then do this when accessing the artifacts:

``` val resolveTransform by tasks.registering {
    inputs.files(resolvedSimple.incoming.artifactView {
       attributes.attribute(specialAttribute, objects.named("target"))
    }.files)
    doLast {
        inputs.files.forEach {
            println(it)
        }
    }
} ```

Ah, so the documented example works because with `artifactTypes.getByName` you set the attribute on the artifacts, not on the configuration and when resolving the configuration the attribute is ignored because the producer configuration does not have the attribute at all, right?

Is there also a way to "fix" the producer side of OP's example, so that the attribute is set on the artifact, not on the configuration?

Thanks. This helps a lot. I indeed can make it work by putting more on the outgoing configuration:
```val artifactAttribute = Attribute.of("my-artifact-attribute", String::class.java)
val variantAttribute = Attribute.of("my-variant-attribute", String::class.java)

val outConf by configurations.creating {
    isCanBeResolved = false
    isCanBeConsumed = true
    attributes {
        attribute(variantAttribute, "my-variant")
    }
    outgoing {
        attributes.attribute(artifactAttribute, "archive")
        artifact(packing.flatMap { it.archiveFile })
    }
}```
Now I can consume it with:
```val resolvedTransform by configurations.creating {
    isCanBeConsumed = false
    isCanBeResolved = true
    attributes {
        attribute(variantAttribute, "my-variant")
        attribute(artifactAttribute, "folder")
    }
}

dependencies {
    registerTransform(ArchiveUnzipTransform::class.java) {
        from.attribute(artifactAttribute, "archive")
        to.attribute(artifactAttribute, "folder")
    }
}```
Now for the extra bonus question: I'm trying now to publish the original project using maven-publish and an adhoc component associated with the outgoing configuration. But when I do so, the module.json only contains the attributes declared on the configuration, not on the artifacts. Is there a way to have artifact attributes in Gradle metadata?
```  "variants": [
    {
      "name": "outConf",
      "attributes": {
        "my-variant-attribute": "my-variant"
      },
      "files": [
        {
          "name": "emptygradle-1.0.zip",
          "url": "emptygradle-1.0.zip",
          "size": 55189,
          "sha512": "5c9cc018ea1bb3120fccb580c8cd6e6c10e01fc09290bff4aafc176f460dda166ec6e9cbfd1dbf945fc62c021547cfdcc2a6b40efd9005c0aef671317d2af1ff",
          "sha256": "319fc9ea8b5286008767cbfea6768d6f3f1b9662a673035b58752e8f55ba6116",
          "sha1": "38df937c82a209b8890c55c76f986c13a6ca8be0",
          "md5": "12429093d4a5d57405d1c9ae2c62b258"
        }
      ]
    }
  ]```

And if I put "my-artifact-attribute" on the variant, I end up with the same problem as before: Gradle rejects the variant.

Cool. I forgot about the fact that you can put attributes on the artifacts directly on the producer side!

Unfortunately, I think publishing them is a missing feature. :confused: I don’t know if there is an issue for that already. But it sounds like that should be added.

As far as I recall, you can only set attributes that are published on the “outgoing variants”
And then all the attributes from the variants are automatically put on *all* artifacts of the variant. The issue with that is, that the attribute that you set is now *also used for matching* variants. Although the use case is only about the artifacts. (And you might break the matching in a weird way although you don’t want to change it at all. Which is happening in your example.)

`artifactTypes.getByName..` thingy is a way to “patch” this on the consumer side. You can give certain attributes to certain artifacts. But the API is very limited (I think it’s incomplete, it feels like something that was done to get it working _somehow_ but then it was never revisited). Some time ago I was trying to improve that, but never got to a point to really specify what it should be (<https://github.com/gradle/gradle/pull/12089>). But maybe instead of improving that, there should be the option to publish the attributes on artifacts (and fix them with component metadata rules if needed). Then the `artifactTypes`  thing could probably be removed…

In your example, when do you get the matching error?

If you add the `attributes.attribute(artifactAttribute, "archive")` to the configuration instead of the artifact, it should be published.

And matching should still work, as you do not say anything about the `artifactAttribute` on the consumer side. It should be ignored then.

If you only use `artifactAttribute` in the artifact view (and not the configurations) on the consumer side.

Yes, but it would be really cool to be able to use directly the configuration. I think I see what is possible now. I also feel something is missing for this to be seamless, especially in the scenario where you want resolution to work both as a project dependency through a composite build or as an external dependency.
Thank you again for the help and precisions.

So, in conclusion, for the artifact transform to work at all on an external dependency, you HAVE to rely on adding attributes on artifacts. And the different ways I see it can be done is:
• artifactTypes
• artifactView
Component metadata rules seem to be out, because I don't see any API that can add attributes on artifacts.
So it would be great if we could publish those artifacts when publishing a component with Gradle?

`aritfactView` is not adding an attribute to an artifact, it requests an attribute for an artifact.
`artifactTypes` can add attributes to a certain artifact type that you can then request later on.
The other way to add attributes to artifacts is to have them inherit the attributes from the configuration.
In your example both, the configuration and the artifact have `something`.
But if you request `target` from the configuration it cannot match the configuration as transform is only for artifact.
If you request `target` through the artifact view, the configuration is matched as the attribute is not requested and then the artifact transform can make the artifacts have the wanted attribute.

Yes. My post wasn't very precise, indeed.
For clarity, let's call the attribute that will be used to trigger the transformation `folder-bundling`. It can have 2 values: `folder` and `ziptree` .
I want to register a transformation that can transform an artifact from a `ziptree` to a `folder`.

At this time, it seems to me:
• an external component on a Maven repository can not have the attribute "ziptree" set on one of its variants (even if it actually is a ziptree) in its Gradle metadata. If it is set, it prevents Gradle from selecting the variant if the requested attribute value is "folder".
• there is no way for an external component to declare attributes on its artifacts in its Gradle metadata.
• to levarage a transformation one has to:
    ◦ use a resolvable configuration with the proper attribute set, but combine it with an artifactTypes declaration to add the necessary artifact attribute.
    ◦ use a suitably configured artifactView of a configuration without the attribute set.
The first one links the transformation to a particular artifactType (extension), which I think shouldn't be necessary.
The second one makes usage complex, especially because the artifactView no longer carries task dependencies, if the external dependency was substituted with a project dependency by a composite build for example.

My feeling is that what is missing to be able to perfectly use the artifact transform is to be able to publish what is necessary on the external component (the fact that the artifact is a tartree), so that the client project running the transform doesn't have to repeat it but can discover it from the metadata themselves.

&gt; • an external component on a Maven repository can not have the attribute "ziptree" set on one of its variants (even if it actually is a ziptree) in its Gradle metadata. If it is set, it prevents Gradle from selecting the variant if the requested attribute value is "folder".
That's halfway right, halfway wrong.
You can have the attribute on the variant, but if you want `folder`, then you must not request it on the configuration but use an artifact view to trigger the artifact transformation after the configuration was successfully selected.
&gt; • there is no way for an external component to declare attributes on its artifacts in its Gradle metadata.
That seems to be correct according to Jendrik
&gt; • to levarage a transformation one has to:
&gt;     ◦ use a resolvable configuration with the proper attribute set, but combine it with an artifactTypes declaration to add the necessary artifact attribute.
&gt;     ◦ use a suitably configured artifactView of a configuration without the attribute set.
I don't think this is fully correct, I'm not sure whether you mean the correct thing though.
If you have the attribute on the resolvable configuration, the variant will not selected, no matter if you use `artifactTypes` or not, because the attributes of the configuration do not match and no transformation can change that.
If the consumable configuration and artifact do not have any attributes set, you can on the consumer side use `artifactTypes...` to add attributes to the artifacts like `minified = false` or `exploed = false` to then use an artifact transform to get them to the value you want to have.
In that case the attribute is only set on the artifact, so you can specify the attribute in the resolvable configuration, as the consumable configuration does not have the attribute and thus it is ignored.
But if the consumable configuration has a value for the attribute, it has to match or be compatible by compatibility rule.
&gt; especially because the artifactView no longer carries task dependencies
Are you sure? I'd really wonder if that is the case.
&gt; to be able to publish what is necessary on the external component (the fact that the artifact is a tartree),
Exact, as Jendrik said. If there is no feature request for that, you should probably open one. :slightly_smiling_face:

&gt; especially because the artifactView no longer carries task dependencies
That’s not correct. An artifactView is an additional lazy layer on top of the configuration. All dependencies are preserved. I think this is a good concept in general.

I agree on the part that it should be possible to publish attributes for (and only for) artifacts. And then also have an API in component metadata rules to adjust these if necessary.
After this (good and interesting) discussion my feeling is that this is the missing piece to make things clearer and avoid “hacks”.

<@U03F7S2BRK5> Maybe you find this interesting. I remember that you were asking about feedback on issues with variant-aware dependency management some time ago. Do you happen to know if there is an issue already about “publishing artifacts attributes”? (cc <@UAB9WQKJ4>)

&gt;&gt; especially because the artifactView no longer carries task dependencies
&gt; Are you sure? I'd really wonder if that is the case.
Sorry, you're right, it seems to work. And all your remarks are in synch with my current understanding, even if my posts may suggest otherwise.
I'll try to open a feature request for artifact attribute publication and modification, if it is indeed the direction that Gradle needs to go.