Skip to content

Conversation

timtebeek
Copy link
Member

What's changed?

Fail hard on failure to resolve dependencies, as opposed to continuing with partial type information.

What's your motivation?

Partial type information can lead to missing changes, and hard to trouble shoot issues. We'd rather fail fast and hard, such that the underlying issues can be addressed.

Anything in particular you'd like reviewers to focus on?

Not too familiar with Gradle plugin development; throwing a GradleException seemed the best fit to achieve something similar to what we did in the Maven plugin.

@timtebeek timtebeek self-assigned this Sep 12, 2024
@timtebeek timtebeek added the enhancement New feature or request label Sep 12, 2024
Copy link
Collaborator

@shanman190 shanman190 left a comment

Choose a reason for hiding this comment

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

LGTM!

GradleException, or any other exception, will result in the task being marked as failed.

implementationClasspath = emptySet();
throw new GradleException(String.format("Failed to resolve the dependencies from %s:%s; " +
"We can not reliably continue without this information.",
subproject.getPath(), implementationName), e);
Copy link
Member Author

Choose a reason for hiding this comment

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

As discussed internally we agreed in principle with throwing an exception; now need to replicate this to the other instances where we call resolve(); some of those hadn't yet done any exception handling, so need a bit of time to figure if throwing is even necessary there.

Copy link
Collaborator

Choose a reason for hiding this comment

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

So just a question, but is the default Gradle exception not sufficient when resolution fails? In this case, were creating a resolvable configuration where we may have had one that wasn't resolvable.

@timtebeek timtebeek marked this pull request as draft September 17, 2024 08:31
@timtebeek timtebeek closed this Nov 29, 2024
@timtebeek timtebeek deleted the fail-hard-on-failure-to-resolve-dependencies branch January 14, 2025 20:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

2 participants