RAT-163: WIP Gradle plugin

[snazy]

RAT-163: WIP for a Gradle Plugin.

Still in a very early stage (no tests, plugin build not integrated, and more).

Added some notes in apache-rat-gradle-plugin/README.md.

[ottlinger]

Thanks for your work .... apart from the functionality some questions remain to be solved:

• as RAT is released as a monolith - is that fine with the gradle plugin? Or does the plugin need a different lifecycle?
• is the HTML report similar to the stuff mentioned in RAT-395?

In RAT 0.17 we tried to fix the inconsistent naming; thus "RAT" should be used in all customer-facing places ;)

@snazy I pushed some minor changes to the branches, so at least the Maven build seems to go through.

[snazy]

* as RAT is released as a monolith - is that fine with the gradle plugin? Or does the plugin need a different lifecycle?

Hm, that's tricky. Gradle plugins are referenced by plugin-IDs, which are translated to Maven coordinates. The most convenient way for users is Gradle's Maven repo one. But it's not a big deal to use Maven Central in Gradle builds.

* is the HTML report similar to the stuff mentioned in [RAT-395](https://issues.apache.org/jira/browse/RAT-395)?

Oh! That's interesting, I didn't know about this ticket. I just picked "some" XSL for now to keep "feature parity". From a brief look, the XSL I've chosen doesn't expose all information. I'd prefer to change it to the one mentioned in RAT-395.

In RAT 0.17 we tried to fix the inconsistent naming; thus "RAT" should be used in all customer-facing places ;)

GTK! :)

[ottlinger]

@snazy the RAT report changed fundamentally in release 0.17 as it expsoses much more information and information categories now. I'm still uncertain which information is needed/useful for clients, but it would be a great way to start with an XSL and get more feedback from user's. Any Gradle user is of help ;)

[snazy]

I think this PR is pretty close. It just does its thing and the non-generated code isn't overly complex ("just" Gradle-ish), thanks to the generated property/configuration code.

Most of the TODOs are done now:

• tests
• Maven build integration (no CI workflow change necessary)
• The plugin's configured in "the Gradle way" (using it's specialized Property types)

This PR also depends on the Java "minimum" requirement.

Open TODOs:

• Fix Maven 'verify' - the added smoketest fails
• use the RAT project's code style (and not the Google one).
• Documentation (probably worth to tackle that separately)

I left the HTML report "broken" for now. Maybe worth to spill that work out to a separate PR?

[Claudenw]

If Gradle needs an HTML report (as does Maven Report plugin) then perhaps following the anticipated Maven pattern may make sense.

My plan to fix Maven is to have the "check" part of the plugin write an XML file into the target space somewhere. Then the "report" part of the plugin will read that XML and generate a report from it.

There is also a request to generate multiple reports on a single CLI run. So I expect that the output-style will change to allow multiple style sheets. Not sure how exactly but we can work through that.

My point here is that the gradle plugin could generate an XML output in some directory and do this by setting the current output-file setting. Then run one or more XSLT on that. Alternatively, if you would normally generate the output in one go, then create an XSLT that produces what you want and we can see about adding it as a named XSLT.

On the question of monolith I am moving toward the UI as a separate package. If each of the UIs is a separate package then we can strip the core down to the minimum necessary to support all the standard CLI options, and put the reporters in separate jars bundled with core and tools.

So apache-rat-<version>.jar is the CLI version apache-rat-maven-<version>-<mavenversion>.jar is the maven plugin version that requires <mavenversion> of maven. apache-rat-ant-<version>-<antversion>.jar is the ant component version that requires <antversion> of Ant. apache-rat-gradle-<version>-<gradleversion>.jar is the gradle component version that requires the <gradleversion> of Gradle. apache-rat-core-<version>.jar is the core component used by and embedded in all the UI versions.

The current tools component gets broken up and distributed so that all the common bits are in core and all the UI specific bits are in the UI plugins.

This will pose a problem for documentation generation but I think it will be minor and we can overcome it.

[Claudenw]

I have put forward a design proposal [1] that includes this PR and how we should think about UIs going forward. Please take a look, join the mailing list if you have not already done so, and let's have discussion about how to support the various flavours of UI going forward.

[1] https://lists.apache.org/thread/5d9cx2wzll2h0g7y9sybp68m7whxcd9h

[snazy]

If Gradle needs an HTML report (as does Maven Report plugin) then perhaps following the anticipated Maven pattern may make sense.

Gradle doesn't need it. I just added it as this plugin created an HTML report as well.

My plan to fix Maven is to have the "check" part of the plugin write an XML file into the target space somewhere. Then the "report" part of the plugin will read that XML and generate a report from it. There is also a request to generate multiple reports on a single CLI run. So I expect that the output-style will change to allow multiple style sheets. Not sure how exactly but we can work through that.

That sound great! The Gradle plugin can follow this mechanism, and I think that's the most flexible approach. It's rather a technical detail what and how "all the stylesheets" are processed. If that's pluggable, even better!

On the question of monolith I am moving toward the UI as a separate package. If each of the UIs is a separate package then we can strip the core down to the minimum necessary to support all the standard CLI options, and put the reporters in separate jars bundled with core and tools.

That's doable. We just need what's in the apache-rat-core module. When the reporters are pluggable, we can also allow custom reporters. That's relatively easy, the actual report generation is running as a "classloader isolated" Gradle work action, we and users can add whatever they want there.

So apache-rat-<version>.jar is the CLI version apache-rat-maven-<version>-<mavenversion>.jar is the maven plugin version that requires <mavenversion> of maven. apache-rat-ant-<version>-<antversion>.jar is the ant component version that requires <antversion> of Ant. apache-rat-gradle-<version>-<gradleversion>.jar is the gradle component version that requires the <gradleversion> of Gradle. apache-rat-core-<version>.jar is the core component used by and embedded in all the UI versions.

SGTM! It's not common to add the (minimum) Gradle version to plugins. Plugins rather define the minimum version it supports.

The current tools component gets broken up and distributed so that all the common bits are in core and all the UI specific bits are in the UI plugins.

+1

I have put forward a design proposal [1] that includes this PR and how we should think about UIs going forward. Please take a look, join the mailing list if you have not already done so, and let's have discussion about how to support the various flavours of UI going forward.

Will do!

[snazy]

Ugh! Guess I have to remove all the dust from my antique Windows knowledge and port this to Windows.