This message was deleted.

You should use custom publications instead: https://docs.gradle.org/current/userguide/publishing_customization.html#sec:publishing-custom-components

Do you know of a specific example? This seems like a lot to go through to simply change a version or few. The component I want to publish is the java component, just with these version changes.

Any change to a

pom.xml

file is a code smell IMO. So either it means you have custom publications and they should be modeled as such, or it means that the initial declarations were wrong. I cannot really tell from what you are explaining. Maybe there's another way for your particular use case.

Also you asked "What is the proper way" and the answer is exactly what Cédric said, fix your model so that the generated files are what you expect / need. For the Gradle module metadata also no equivalent like

withXml

exists because you are not supposed to manipulate it but to fix your model. The only way to still hack-around (still, because

withXml

also imo is bad), would be to register some

doLast

action on the generation task that then modifies that actual generated file. But really, better fix your model so that the generated file is what you expect / need.

The dev teams are fixing the underlying issue and as I originally said, I know that this is a workaround. Specifically, we have projects that have cyclic dependencies among them and the workaround references a previous publication, and then the local jar file on subsequent builds. This later workaround custom resolver. Unfortunately, the workaround attributes are being used in publishing the pom/metadata and needs to be corrected. This workaround has been used for several years and has worked for our build because transitive dependencies have not been enabled. Now we are enabling transitive dependencies and the published dependencies are incorrect in this case. In summary, I agree that there is an issue with the component model itself. But, for now it is what it is and I am looking for the best way to modify the metadata to be proper for our (probably unique) situation.

maybe publishing the resolved versions would work for you: https://docs.gradle.org/current/userguide/publishing_maven.html#publishing_maven:resolved_dependencies

That is what is already done. And this resolved version is the one that is incorrect.

instead of

fromResolutionResult()

, you could use

fromResolutionOf(yourConfiguration)

, and have your configuration something which extends, say,

runtimeClasspath

, and defines its own resolution strategy rules

configurations.yourConfiguration.resolutionStrategy { ... do the substitutions here ... }

.

This is a possibility that seems worth attempting. I will give it a try and let you know if it works for our case. Thanks

Maybe you want to also post your solution to the forum. 🙂