-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add flag to update only explicitly listed dependencies #27
Conversation
@patrikerdes hi, can you take a look? Thanks! |
I really like this feature. Also having the option to ignore some dependencies would be really helpful. |
@usr42 you can do that in; https://github.com/ben-manes/gradle-versions-plugin |
Hi! |
Great, thanks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have reviewed your changed and tested this out and it has been working just fine for me so far, except for a minor comment related to the message when an update fails.
int failedCount = leftToUpdate.size() | ||
int skippedCount = updateWhitelist.empty ? 0 : | ||
leftToUpdate.count { !updateWhitelist.contains(it.groupAndName()) } as int | ||
int failedCount = leftToUpdate.size() - skippedCount | ||
if (failedCount > 0) { | ||
println("useLatestVersions failed to update $failedCount ${deps(failedCount)} " + |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If one --update-dependency
flag is used on the command line and that update fails, failedCount
will be 1, but leftToUpdate
could have more than one update that has not been done which is printed, e.g.
gradle-use-latest-versions-plugin\examples\localReadmeExample> .\gradlew useLatestVersionsCheck --update-dependency commons-lang:commons-lang
useLatestVersions failed to update 1 dependency to the latest version:
- com.github.ben-manes.versions:com.github.ben-manes.versions.gradle.plugin [0.16.0 -> 0.21.0]
- commons-codec:commons-codec [1.9 -> 1.12]
- commons-lang:commons-lang [2.4 -> 2.6]
- commons-logging:commons-logging [1.1.2 -> 1.2]
- junit:junit [4.0 -> 4.13-beta-3]
useLatestVersions skipped updating 4 dependencies not in --dependency-update:
- com.github.ben-manes.versions:com.github.ben-manes.versions.gradle.plugin [0.16.0 -> 0.21.0]
- commons-codec:commons-codec [1.9 -> 1.12]
- commons-logging:commons-logging [1.1.2 -> 1.2]
- junit:junit [4.0 -> 4.13-beta-3]
This looks a bit strange to me. To me it would make more sense to only print the single update which was specified with --update-dependency
and that failed in the first list:
gradle-use-latest-versions-plugin\examples\localReadmeExample> .\gradlew useLatestVersionsCheck --update-dependency commons-lang:commons-lang
useLatestVersions failed to update 1 dependency to the latest version:
- commons-lang:commons-lang [2.4 -> 2.6]
useLatestVersions skipped updating 4 dependencies not in --dependency-update:
- com.github.ben-manes.versions:com.github.ben-manes.versions.gradle.plugin [0.16.0 -> 0.21.0]
- commons-codec:commons-codec [1.9 -> 1.12]
- commons-logging:commons-logging [1.1.2 -> 1.2]
- junit:junit [4.0 -> 4.13-beta-3]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. Will fix.
In many larger projects, users often want to update only specific dependencies as updating everything at once may be too large of a change. Provide such functionality through a Gradle @option on the two task classes. While this @option API exists only from 4.6 up, this is not a breaking change for lower versions of Gradle as missing annotation types are simply ignored when classes are being initialized (JLS §13.5.7).
7c9f15a
to
35361c1
Compare
How's that @patrikerdes? |
LGTM |
Released in 0.2.12 |
I've opened a PR for this: #35 |
In many larger projects, users often want to update only specific dependencies
as updating everything at once may be too large of a change. Provide such
functionality through a Gradle @option on the two task classes.
While this @option API exists only from 4.6 up, this is not a breaking change
for lower versions of Gradle as missing annotation types are simply ignored when
classes are being initialized (JLS §13.5.7).