GrettyPluginAction sets buildingProduct incorrectly

[Octogonapus]

In GrettyPluginAction, the field buildingProduct is set based on whether the substring buildProduct is in any of the task names from project.gradle.startParameter. This requires that I start a task with buildProduct in the name if I want to use the task buildProduct as a dependency. Otherwise, this code is not run so the jar I'm trying to build is missing files: https://github.com/devsoap/gradle-vaadin-flow/blob/3d3e9f9770a4e45e31c9a5e4efee08e55ad363f4/src/main/groovy/com/devsoap/vaadinflow/actions/GrettyPluginAction.groovy#L110

I think buildingProduct should be detected in another way that does not require the substring buildProduct to be part of project.gradle.startParameter.taskNames.

[johndevs]

I agree with this but we need to figure out how to detect when the user is building a product in another way. When this was implemented last time there was no apparent way of doing this other than checking the command line parameters. Maybe there is now?

[Octogonapus]

@AustinShalit You had an idea about walking the task graph?

[AustinShalit]

Yea. I think @JLLeitschuh knows how to do it better than I do though.

[JLLeitschuh]

def blah = false
gradle.taskGraph.whenReady { blah = it.hasTask("myTaskName") }

Doing the above is a huge anti-pattern though. Really, you shouldn't be reconfiguring your task graph dependent upon whether or not another task will be executed.

If you need to do a custom configuration to a task because of another task, you probably should have your plugin create it's own instance of the jar task and modify how that one behaves. Or just always configure the jar task.

[johndevs]

The issue is that if we are building a product then we will need to add all the resources into the JAR while when not building a product (a WAR for example) we don't want to add the resources to the JAR as they will be added to the WAR.

I would rather not add a custom JAR as then it might be confusing for users to understand how this jar differs from the other jar.

So that leaves me with the anti-pattern version to go forward with at least for now. Thanks for that solution!