Closed DimaSol closed 12 months ago
Looks like further debugging led me to find the root cause which is a combination of the plugin together with the https://github.com/nebula-plugins/gradle-lint-plugin plugin because the lint plugin is configuring tasks for the linting...
Hello,
The result is unclear for me.
Is this issue due to the lint plug-in? In which case there is nothing to do in the graphql-gradle-plug-in-project.
Or is there an issue in the graphql-gradle-plug-in-project?
IMO the issue is with the graphql plugin assumption on when does the task configure method is called and this assumption doesn't hold in combination with the lint plugin...
Hello, this is solved in release 2.3
Hi, I think I have an issue that is caused by same reason as https://github.com/graphql-java-generator/graphql-gradle-plugin-project/issues/13 From debugging the plugin I've found that each and every tasks of this plugin is being registered as a dependency of the
compileJava
task which is wrong (only the tasks that are configured should be registered as a dependency ofcompileJava
) i.e. I only havegenerateServerCodeConf
closure so it should be the only task that thecompileJava
depends on... I'm using the latest version of the plugin:com.graphql-java-generator.graphql-gradle-plugin3:2.2
What I see in debug (of my pretty complex multi project structure) is that whenproject.afterEvaluate(new Action<Project>() {...}
in theGraphQLPlugin#apply
is called, the loop (line 118)for (Task t : project.getTasks()) {
is eventually invoking theconfigure
of all plugin tasks and this method registers the task as a dependency ofcompileJava
. It also seems that the plugin registers the depending tasks twice, once in theconfigure
method of itself and once at the condition ofif ((boolean) t.property("initialized"))
while iterating over all project tasks in theproject.afterEvaluate(new Action<Project>() {...}
callback inGraphQLPlugin#apply
- If this is indeed the case I think the dependency registration in the common taskconfigure
method can be removed, no? Unfortunately I'm not yet able to reproduce with a simple gradle project to provide with an example and I can't share the original project...Attaching the stack trace (please look for the
>>>>>>
sign to indicate the invocations I've mentioned above) when hit a break point in the client code generation task (which is not configured in the gradle build file):