Skip to content
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

Open
simonbasle opened this issue Oct 3, 2017 · 5 comments
Open

Add or document way of comparing against a gradle coordinate #16

simonbasle opened this issue Oct 3, 2017 · 5 comments

Comments

@simonbasle
Copy link
Contributor

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 to force 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.

@pettermahlen
Copy link

Yes, this is how the Maven plugin for japicmp works, and it's very useful.

@sebersole
Copy link
Contributor

Its actually very easy, e.g.

configurations {
    compatibilityBase {
        description = 'Configuration for the base version of Hibernate we want to verify compatibility against'
    }
}

dependencies {
    compatibilityBase 'org.hibernate:hibernate-core:5.0.0.Final'
}

task generateDesignationsReport(type: me.champeau.gradle.japicmp.JapicmpTask) {
    oldClasspath = configurations.compatibilityBase
    ...
}

@simonbasle
Copy link
Contributor Author

simonbasle commented Jan 17, 2019

⚠️ This configuration trick doesn't work for me anymore when the dependency is a different version of the project being built (which makes sense for JAPICMP check). The check ends up comparing the freshly assembled jar to... itself 🤦‍♂️ So it was just silently skipping the check rather than failing visibly 😢

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 force = true in the dependency closure, and dependencyResolution in the Configuration closure, without success :(

The only way I found out of this was to use the download-task plugin de.undercouch.download, using it as an intermediate step between jar and japicmp to download the baseline jar:

jar.finalizedBy(downloadBaseline)
downloadBaseline.finalizedBy(japicmp)

@melix
Copy link
Owner

melix commented Jan 17, 2019

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.

@simonbasle
Copy link
Contributor Author

@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 😉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants