Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 20 additions & 7 deletions build-tools/scripts/src/main/groovy/geode-java.gradle
Original file line number Diff line number Diff line change
Expand Up @@ -118,13 +118,26 @@ gradle.taskGraph.whenReady({ graph ->
}.findAll { !(it.value?.hasProperty('optional') && it.value.optional)})
}

def incoming = geodeProject.configurations.runtimeClasspath.getIncoming()
def resolutionResult = incoming.getResolutionResult()
def components = resolutionResult.allComponents

upstreamDeps.addAll(components.findAll {componentResult ->
depMap.containsKey(componentResult.moduleVersion.id.name)
}.collect {it.moduleVersion.id.name + '-' + it.moduleVersion.version + '.jar'})
// NOTE: Previously this logic resolved the upstream project's runtimeClasspath via
// geodeProject.configurations.runtimeClasspath.getIncoming().getResolutionResult().
// That constitutes cross-project configuration resolution (executed while configuring
// the current project's Jar task) and triggers Gradle's deprecation warning:
// "Resolution of the configuration :otherProject:runtimeClasspath was attempted from a context different than the project context"
// To avoid that, we derive the first-level runtime dependency jar names directly from
// the dependency metadata (depMap) we already collected, without forcing resolution of
// the upstream configuration here. This yields the same set that was formerly filtered
// against the resolved components because depMap only contains declared (first-level)
// non-optional dependencies of the upstream project.
depMap.values()
.findAll { dep -> !(dep instanceof ProjectDependency) }
.each { dep ->
if (dep.hasProperty('version') && dep.version) {
upstreamDeps.add("${dep.name}-${dep.version}.jar")

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we have a fallback if any jar has no version in the filename? Or atleast log it if some depedency is skipped?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @sboorlagadda . That’s a sharp observation. If a jar lacks versioning in its filename, we should either have a fallback strategy or at minimum log it. Skipping silently could lead to subtle issues down the line, and visibility here is key. Let me get back to it and work on it. Thank you so much for your help, @sboorlagadda

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @sboorlagadda,
I've incorporated your suggestion to reflect the skipped dependency. Thanks for the thoughtful input—much appreciated! Please let me know if there's anything else I missed. Thank you.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you

} else {
// Log warning about missing version but don't add to upstreamDeps (preserves original behavior)
logger.warn("Dependency '${dep.name}' has no version information in project '${geodeProject.name}' and will be skipped from upstream exclusion")
}
}
}
// TODO: can we put our projects on the ClassPath line still?
runtimeSet.removeAll(upstreamDeps)
Expand Down
Loading