japicmp
japicmp copied to clipboard
Semnatic version not extracted from jar filename when using CLI
Hi,
I'm currently integrating japicmp into our gradle build to help the team detect changed that would require more than patch version changes according to semver. Calling japcmp and generating the report works just fine, but I'm unable to use the --error-on-semantic-incompatibility flag. That's how it's integrated in our gralde build:
`task apiCompatibilityCheck(type: Exec) { dependsOn assemble
commandLine = "java"
args = ["-jar", "${rootProject.configurations.compatibilityCheckLibrary.first()}",
"--old", "${rootProject.configurations.compatibilityCheckCaasApi.first()}",
"--new", "${project.jar.outputs.files.getFiles().first()}",
"--ignore-missing-classes",
"--error-on-semantic-incompatibility",
"--html-file", "${project.buildDir}/compatibilityCheck.html"]
}`
So pretty forward. The message I get after the report was generated is as follows:
Sep 20, 2019 11:32:09 AM japicmp.output.incompatible.IncompatibleErrorOutput info INFORMATION: Skipping semantic version check because all major versions are zero (see http://semver.org/#semantic-versioning-specification-semver, section 4).
The filenames do dontain the semver version, it's something like caas-api-2.10.0.jar and caas-api-2.10.4-SNAPSHOT.jar.
I digged around in the code a bit and found the place where old and new jar are picked up: https://github.com/siom79/japicmp/blob/bff91db5c8ef04ecbd82010a12b84c6439eaea34/japicmp/src/main/java/japicmp/cli/CliParser.java#L40 and the problems seems to be the call to createFileList: https://github.com/siom79/japicmp/blob/e415556afd2a3d788b4e73b858e2c92bfe2b9fb6/japicmp/src/main/java/japicmp/util/FileHelper.java#L31 which will not handle the versions at all.
So am I doing something wrong or is this feature just not implemented for CLI usage? Using https://github.com/siom79/japicmp/blob/ac729c69f45c36a2df3b8d5dff039e6608d2603c/japicmp/src/main/java/japicmp/versioning/Version.java#L23 it seems to be solvable, but mybe I'm just holding something wrong and it's meant to be used somehow else?
Best regards Chris
Have you tried the gradle plugin?
No, but as far as I see it does not support the error-on-semantic-incompatibility usecase?