https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
a
do you want a general solution, or something specifically for this Jackson dependency?
j
A general solution, my actual usecase is pretty complicated and I was just trying to simplify it, hopefully what I'm actually trying to achieve is clear
The thing I'm thinking of doing, probably looks something like so
Copy code
configurations {
    springBom
}

dependencies {
    springBom "org.springframework.boot:spring-boot-dependencies:2.7.4"
}

def springBootComponent = configurations.springBom.incoming.resolutionResult.allDependencies.collect { it.selected.id }

def springBootBom = project.dependencies.createArtifactResolutionQuery()
  .forComponents(springBootComponent)
  .withArtifacts(MavenModule, MavenPomArtifact)
  .execute()

for (component in springBootBom.resolvedComponents) {
  component.getArtifacts(MavenPomArtifact).each {
    def xml = new XmlSlurper().parse(it.file)
    // do some crazy stuff here
  }
}
v
Use rich versions? So if you declared that version as strict it should win for example
a
try looking at a ComponentMetadataRule, specifically this example that removes transitive dependencies https://docs.gradle.org/8.1.1/userguide/component_metadata_rules.html#fixing_wrong_dependency_details
the short summary is you want a way of prioritising one BOM over another? Which makes sense, but I haven’t see any way of determining the origin of a dependency, which would make defining some ‘resolve conflict’ rule possible https://docs.gradle.org/8.1.1/userguide/dependency_capability_conflict.html
j
Yeah that's correct what you say is the concise way to put it, with the caveat that I want to do it at the 'composite' bom level rather than at the consumer of the composite bom level. Thank you both, you've given me some things to think about. I had sort of forgotten about this gradle module metadata thing, because I primarily just use poms, but I could definitely make an exception if it lets me resolve this.
a
okay, here’s a theoretical and confusing, but more-or-less Gradle compatible, idea: in composite-bom: 1. create a new configuration, 
priorityApi
2. make the existing 
api
configuration extend 
priorityApi
3. add an additional ‘priority api’ attribute to all dependencies in 
priorityApi
(I’m not quite sure if this is possible) 4. now there’s a ‘marker’ that can be used to determine the origin of a dependency when selecting between candidates - if the candidate has the ‘priority’ attribute then it should be preferred 5. add child-bom as a platform dependency of 
priorityApi
👍 1
j
Hmm yep, that's a good sounding idea, makes a lot of sense!
👍 1
a
for step 3 maybe this works
Copy code
configurations.create("priorityApi") {
  withDependencies {
    configureEach {
      if (this is ModuleDependency) {
        attributes {
          attribute(project.objects.named("PriorityApi"), "priority")
        }
      }
    }
}
Open in Slack
PreviousNext
Powered by