Skip to content

Core locking ergonomics with write-locks and update-locks #66

@OdysseusLives

Description

@OdysseusLives

Given a project uses Gradle core locking
And locks are in use,
When a dependency resolves to a new version
And --write-locks and --update-locks with a group & artifact are both invoked,
Then the user should be informed that these should not be run at the same time

Here is a sample project that walks through this scenario: https://github.com/nebula-plugins/gradle-nebula-integration/tree/master/locking-ergonomics

In the end, the update-locks is used (which is better than unlocking & resolving all dependencies), but it would be better to warn the user.


Looks like these values are set here in the DefaultDependencyLockingProvider[1] and then get used in the LockEntryFilterFactory.forParameter(...) where if there are no dependencies to update, then a FILTERS_NONE is returned. But if there are selective dependencies to update, then only those are updated.

[1]https://github.com/gradle/gradle/blob/master/subprojects/dependency-management/src/main/java/org/gradle/internal/locking/DefaultDependencyLockingProvider.java#L69-L75
[2]https://github.com/gradle/gradle/blob/master/subprojects/dependency-management/src/main/java/org/gradle/internal/locking/LockEntryFilterFactory.java#L45-L67

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions