This message was deleted.
# community-support
s
This message was deleted.
v
Your solution should be fine. When configuring the root project the subproject is not yet configured and so you don't find the task yet. By using the string-y version the searching for the task is delayed. Besides that, my statement is just true if you only want the pure task dependency but do not want to use the output of that task. Explicit
dependsOn
is always a code-smell unless the left-hand side is a lifecycle task. If you actually need the outputs of that task in the other project, you should use the proper cross-project publication means as documented at https://docs.gradle.org/current/userguide/cross_project_publications.html
j
I had a lot of
dependsOn
that I have to put related to the Gradle 8.0 upgrade. Should be great a guide about how to avoid them, for example when I codegen some sources, detekt task cries, and so on.
v
Properly wire task outputs to task inputs or other places. For code-generation tasks for example make sure the task has properly defined its outputs and the set the task itself as
srcDir
for the source set. Then any part requesting sources like compilation task, source jar task, and so on, automatically get those sources and the needed implicit task dependency. In case of generated code you only have a problem if the code generation also uses the sources as input. Then you would have a circular dependency and have to check on a case-by-case basis how to properly do it.
j
I will check the SourceTask, thanks!
s
its an intellij plugin, I don't need to consume artifact in the root project, the root project is going to run a task that will package the plugin from the build folder, i just want the rider project to write some files to there before the packaging.
v
If I got you right, that this task copies files into the output directory of some other task, don't do that, that causes a sh**load of problems. Each task should have a dedicated output directory which no other task uses. If you need the outputs in some other task, wire them together. For example configure the packaging task to copy the outputs of that task, then you automatically have the necessary task dependency when actually needed.
s
So if i have in the root project a prepareSandbox task, i want in the sandbox two dlls from rider sub project, should i do the copy in the prepareSandbox task of the root project ?
v
You should use proper cross-project publication of these dlls in the subproject and retrieving in the root project like documented at the link i gave you. You should not have a task in the subproject that writes into the build directory of the root project and is depended on by the root project.
s
OK, I will do. Thanks!
👌 1
I did it and its much better and cleaner, all the dependsOn and other issues i had are gone. Thank you!
👌 1
j
@Vampire do you have any public SourceTask? I cannot get it working
I get the codegen working with
SourceTask
but I am still getting the same error
Copy code
Reason: Task ':detekt' uses this output of task ':generateProjectData' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.
I am missing something? I added the task to the
srcDirs
but now I am getting
Copy code
* What went wrong:
Could not determine the dependencies of task ':check'.
> Could not create task ':detekt'.
   > Failed to query the value of extension '...' property 'includes'.
      > Stack overflow during pattern compilation near index 4
        ((?<=\p{Ll})\p{Lu}|\p{Lu}(?=\p{Ll}))
            ^
found the issue and an improvement, I was adding
build/generated
to detekt inputs which was bad in first instance 🤦‍♂️
👌 1
v
Exactly, don't configure paths except in the beginning of the chain, but wire outputs to inputs