Default inferredScope setting

[rgozim]

I am currently toying around with reckon in a composite build project, and found that ReckonExtension isn't able to detect/pickup prosperities, such as -Preckon.scope=patch from the command line.

Step wise debugging through the code, I find that the debugger evaluates to

reckon/reckon-core/src/main/java/org/ajoberstar/reckon/core/Reckoner.java

Line 86 in e71521a

scope = inferredScope.orElse(Scope.MINOR);

and this is where the incorrect scope is assigned/defaulted from.

I wonder if having an option at configuration time in the reckon plugin block to set a default scope would be a solution to this? For example:

reckon {
    scopeFromProp {
        default = "patch"
    } 
}

I guess I should also add, in this line

reckon/reckon-gradle/src/main/java/org/ajoberstar/reckon/gradle/ReckonExtension.java

Line 74 in e71521a

.filter(value -> project.getGradle().getParent() == null)

why not trust the properties of a composite parent? If the code should happen upon the property "reckon.scope", would that not be a very specific property that has probably been intentionally set?

[ajoberstar]

The rationale for ignoring the parent Gradle in a composite build is that it's not clear to me that the scope or stage you choose for one project will always match what you would choose for all projects in the composite build. I'm generally assuming that the primary project in the composite is the only one you would be doing a release from. May be inaccurate, and may need to be better clarified in the output, but it seems like a safer behavior.

Not sure how the default ties to this use case. Any further context on that one?

[rgozim]

I have a gradle plugin project called project_plugin, a bit like your gradle-defaults project, which configures the reckon plugin and sets in code project.ext.set("reckon.scope", "patch") as I wish to favour patch increments rather than minor for my gradle plugins.

The thing is, is I have a composite top level project which can assemble all subprojects, which includes the project_plugin I just mentioned. When doing gradle assemble from the composite project, the configuration of the project_plugin is ignored and instead of each subproject bumping their patch version, the minor version is bumped.

I've made an example here https://github.com/rgozim/plugin-composite

• gradle assemble from the top level composite build shows minor versioning.
• gradle assemble from either pluginB or pluginC shows patch versioning.

[ajoberstar]

Ah, I see. So I really only want to avoid having the command line property (or parent project, in general) inherit down to the included builds, but if they're explcitly setting the property as with the plugin you have that should be allowed. Will have to look into how to pull that off.