Provide a Gradle plugin

[oehme]

Continuing the discussion from junit-team/junit5#483:

It would be cool if Degraph came with a Gradle plugin that allowed users to check their Java code for violations. I did a very rough sketch of a Degraph task in the JUnit repository.

Ideally the plugin should have the following characteristics:

• Users have a simple way to define slicings and constraints (doesn't need to be a Groovy DSL. Gradle's checkstyle plugin uses checkstyle.xml config for instance)
• for each Java sourceSet, a Degraph check task is automatically created
• the Degraph check tasks are hooked into the Java plugin's check task
• the plugin works with future version of Degraph without needing to be upgraded itself
• The plugin does not depend on Degraph directly. Instead it resolves it at runtime and invokes it in a forked process. This way it does not pollute the plugin classpath (ASM is especially problematic, as so many tools depend on so many different versions of it)
• (If Degraph is extensible?) users can write custom extensions in the project being checked

The DSL could be as simple as this, assuming the configuration is written in an XML file. The rest is wired up automatically.

degraph {
  version = '1.0.0' //use some hardcoded default if the user doesn't specify
  configuration = "$rootDir/gradle/config/degraph.xml"
}

The plugin and task should be pretty straightforward. The only thing I'm not sure about is: Is there already a configuration file format that allows users to specify slicings and constraints? Is there a class with a main method that fails if violations are found?

[obecker]

I have started writing a gradle plugin that allows expressing degraph constraints in a Gradle DSL, see gradle-degraph. Any thoughts on this would be welcome.

Concerning your ideas sketched above: the plugin is not independent of Degraph and uses the current version 0.1.4. Also it creates currently only one degraph task that analysis the union of all source sets' outputs (which doesn't seem too bad, since you wouldn't probably allow a dependency a->b in the production code and at the same time a dependency b->a in the tests).

[oehme]

Thanks for starting this!

The plugin shouldn't depend on degraph, it should allow the user to choose the degraph version in their build. Otherwise you are binding your release processes together and users are unable to use fixes in your plugin without also accidentally updating degraph and vice-versa. Also, since degraph depends on ASM and this is a very common dependency, you are likely to get classpath conflicts with other plugins. See our plugin best practices for an example of resolving a tool only at runtime.

Also, checking all source set outputs in one go would be wasteful if the user is only interested in checking the main sources for instance. Therefor I think there should be one task for each source set.

[schauder]

There are very reasonable use cases to not use Degraph on tests or with a different rule set.

Degraph basically forces you to pull all integration tests way up in your dependency graph. I'm personally very fine with that but many others aren't.

In any case having a first limited version is way better than not having any. So 100 thanks for your effort!

[obecker]

Ok, I have changed my implementation to create multiple tasks, one for each (configured) source set. A first version has been published in the gradle plugin repository.

To build a plugin that doesn't depend on degraph directly we need changes in degraph, IMO. It requires a configuration format to express the dependency constraints and an API independent way to start a degraph process.

[obecker]

I have released an update to the gradle plugin (v0.1.4.1) that resolves two of the issues mentioned above:

• it uses a dedicated classpath for running degraph, so the degraph dependencies don't appear in the dependencies of the plugin (I had indeed a problem with ASM in one of my projects)
• it allows configuring the degraph version to be used (this was a side effect of the first issue - originally I had a different solution in my mind ...)

Btw: @schauder, do you intend to continue working on degraph? It would be a pity if this project stops getting maintained.