Complicated default logic driving me crazy


(Steve Cohen) #1

OK, I have a complicated implementation situation involving two layers of applied plugins and conventional behavior.

On the top level (a revision I’m making to the os.neblula rpm plugin), I add a variable to the Rpm task called changeLogFile:

    @InputFile @Optional
    File changeLogFile

On the next level down, in a plugin that applies the top level plugin, I want to set a default value for this property.

On the build script level I want to provide the option to disable this, i.e. to set the value back to null.

The problem is that no matter how I sequence the configurations, if the file does not exist, I cannot seem to find a way to set the default value to null in a timely fashion. Even using beforeEvaluate { changelogFile = null }, in the build script I am failing, because setting the default happens as the plugin is applied.

I’ve even gone to the extreme of having the build script set a disabled flag in the task in a beforeEvaluate block and not setting the changeLogFile itself in an afterEvaluate block if the disabled flag is not set, and I still get the error. Even though I suspect this would produce incorrect results on the @InputFile functionality if it worked, but it doesn’t even work.

Is there some way to achieve what I’m after?

Again,
1 users of the top level plugin should have no assumptions made about the changeLogFile. The build logic only applies if the property is initialized.
2. users of the lower level plugin which applies the top level and is applied by build scripts, should expect to have a changeLog file in the default directory unless they somehow configure the task in the build script to disable the feature.


(Steve Cohen) #2

OK, duh. The more I learn the more I forget. The answer is an ext property in the build script defined before applying the plugin.