Add option to configure via semverGit {} block

[emlun]

This allows the plugin to be applied with the new plugins {} DSL.

Fixes #3. Alleviates #14. Fixes #26.

[deepy]

I'll see if I can find something else later, but so far this looks great, just some minor things 👍

[deepy]

Since the Project is only used for projectDir can we remove project entirely?
Makes it a little easier to reason about and also doesn't prevent additional blocks for configuration-cache compatibility

[emlun]

Sure!

[deepy]

I like this clever use of where, unfortunately this also affects the test name giving this test the name: semverGit {} block overrides project.ext settings [config: plugins { id "com.cinnober.gradle.semver-git" apply false } ext.nextVersion = 'minor' ext.snapshotSuffix = 'LEGACYSNAPSHOT' ext.dirtyMarker = '-legacydirty' ext.gitDescribeArgs = '--match *[0-9].abc.[0-9]*.def.[0-9]*' ext.semverPrefix = 'legacy-version-' apply plugin: 'com.cinnober.gradle.semver-git' semverGit { nextVersion = 'major' snapshotSuffix = 'new_<dirty>snapshot' dirtyMarker = '-NEW_DIRTY' gitDescribeArgs = '--match *[0-9].[0-9]*.[0-9]* --long' prefix = 'new-version-' } , #0] in tools and reports 😀

[emlun]

Yes, I noticed that too 😆 I experimented with a few alternatives, none of which really turned out any better:

• Parameterize over the config Map instead of the expanded config file contents

  • This also requires an additional parameter to select which kind of config to generate. It can be embedded into the same configs() return value and setupPluginWithClasspath can "dynamic dispatch" on it, but the resulting test names aren't that much better. Doesn't seem worth the increased source code noise.

• Parameterize over configType << ["legacy", "extension"] instead of the config Map.

  • This works well enough, but then the configType argument (an invariant across all of the tests) gets mingled in with the config Map argument (varies between tests), which entangles two orthogonal concerns. Doesn't seem worth the reduced code clarity.

• Parameterize over the setupPluginWithClasspath function itself instead of its argument.

  • This allows the config Map to stay in the when: block instead (nice!), but makes the test names entirely incomprehensible (they show a closure type instead of the config contents).

[deepy]

Alright, I found the corner-case. It's in this project's build-script 😁
The publishing section in build.gradle needs to use version.toString() otherwise the build fails.

Could you do this change and at the same time use -s on that commit to sign-off the changes?
Previously this repository required a CLA, but before I left the discussion was to replace it with DCO which is basically the same thing but with less paperwork

After that it looks good enough to be merged, I'll have to chase some people to actually get it released though so that might take some extra time