aalmiray / clirr-gradle-plugin Goto Github PK

I didn't dive into this yet. Quick Google search doesn't seem to return good pointers. Running gradle with --stacktrace yields no stacktrace.

:smack-core:clirr
Error executing 'clirr' task. uber.org.apache.bcel.classfile.ClassFormatException: Invalid byte tag in constant pool: 18 

It would be great if the plugin would automatically determine the baseline version automatically, so that I don't have to change it manually between releases.

My project only guarantees API compatibility between patchlevel releases (1.2.1, 1.2.3. 1.2.42, ...), so a simply heuristic could look like

1. Remove the snapshot qualifier, i.e. -SNAPSHOT-X
2. Remove all release qualifiers, i.e. -alphaX, -betaX, -rcX, where X is an arbitrary number of digits
3. If the patchlevel number is
   • 0, then don't run clirr because there is no previous release to test against
   • otherwise decrement the patchlevel by one and run clirr against that release

I ♥ clirr-gradle-plugin, especially since it implemented the nice heuristic I asked for, but clirr doesn't seem to be actively developed any more.

How about switching to an alternative? I did some research, and so far, candidates, with recent commit activity, are

• https://github.com/siom79/japicmp
• https://lvc.github.io/japi-compliance-checker/

On a first look, japicmp looks promising.

I know that https://github.com/melix/japicmp-gradle-plugin exists, but as far as I can tell, it does not follow the nice "convention over configuration" philosophy that clirr-gradle-plugin lives. That is with japicmp-gradle-plugin, I'd have to configure a check for every jar, whereas clirr-gradle-plugin, it is just a matter of applying the plugin.

If I add a new subproject to my gradle build which applies the clirr-plugin to all subprojects, then gradle will fail with "Could not resolve all dependencies", because it tries to resolve the baseline decency of the newly added subproject.

Of course I could configure gradle so that it won't apply the clirr plugin to the new subproject, but it feels like the better approach would be adding a new enabled property to the clirr plugin configuration. This would allow me to

clirr {
    enabled = false
}

in the subproject/build.gradle

Version numbers such as 0.9.2 cannot be parsed by the recently added org.kordamp.gradle.clirr.Version class.

I tried to add support for clirr-gradle-plugin to Smack's build system. It works for subprojects, but as soon as I move the

apply plugin: 'org.kordamp.gradle.clirr'

statement out of the subprojects block, Smack throws the above error message. Of course I want to apply the clirr plugin also on the root project, so that I can define a task like

task clirrRootReport(type: org.kordamp.gradle.clirr.ClirrReportTask) {
     dependsOn = subprojects.tasks.clirr
     reports = files(subprojects.tasks.clirr.xmlReport)
}

The current state of my clirr experiments are Flowdalic/Smack@a8e43f8.
The full error log can be found at http://dpaste.com/3YDZ2E6

I've also try to comment out the jar block in Smack's build.gradle, so that the root project has an jar artifact. Still the result is the same. Help greatly appreciated.