-
Notifications
You must be signed in to change notification settings - Fork 30
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 or document way of comparing against a gradle coordinate #16
Comments
Yes, this is how the Maven plugin for japicmp works, and it's very useful. |
Its actually very easy, e.g.
|
It looks like Gradle (at least in versions as old as 4.10.2) forces to the current version when resolving the dependency. I even tried The only way I found out of this was to use the download-task plugin
|
Gradle doesn't allow a cycle between the root of the dependency graph and itself, so if what you are comparing is the project artifact with a different version of itself, the dependency graph will eventually contain one node, which is what you are seeing. A workaround is to do the compatibility check in a dedicated subproject. |
@melix do you think a "hack" around that (like the above workaround of downloading the jar via an http download plugin rather than Gradle's dependency resolution) could be integrated into the plugin? IMHO it is far from an edge case to want to do the japicmp check against a previous jar (eg. first version in the current maintenance branch), without having to rebuild it, or dedicate a subproject to the check, or jump through too many hoops. If not, documenting the workaround(s) in the README would also definitely help 😉 |
It might be a case of me missing an obvious Gradle feature, but I think it would be beneficial to add support how to compare the jar artifact built by the current build with a baseline jar that is available in a repository (eg. Maven Central), e.g. by providing gradle coordinates to the baseline like
groupId:artifactId:baseLineVersion
.This would eliminate the need to create a specific
configuration
for the base line and add a dependency to the baseline jar in it (which is easy to get wrong, as apparently you also have toforce
that dependency otherwise Gradle can sometimes resolve the actual dependency version to be the same as the currently built, e.g. if the japicmp task doesn't fail the build).If not considered, a fallback would be to at least document how to best achieve that, as it seems to me that requiring the user to manually download the jar into a local folder is a lot of boilerplate.
The text was updated successfully, but these errors were encountered: