buildSearchableOptions fails to find sandbox directory for subproject.

[rhdunn]

I have a project using gradle-intellij-plugin that builds multiple subproject jars (https://github.com/rhdunn/xquery-intellij-plugin). When upgrading to 0.4.8, I get the following error when building for IDEA 2019.1 but not IDEA 2018.1:

> Task :src:intellij-compat:prepareSandbox SKIPPED
> Task :src:intellij-compat:buildSearchableOptions FAILED
FAILURE: Build failed with an exception.
* What went wrong:
A problem was found with the configuration of task ':src:intellij-compat:buildSearchableOptions'.
> Directory '/home/travis/build/rhdunn/xquery-intellij-plugin/src/intellij-compat/build/idea-sandbox/plugins' specified for property 'pluginsDirectory' does not exist.
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 3m 58s

See https://travis-ci.org/rhdunn/xquery-intellij-plugin/jobs/539671597#L607.

NOTE: I'm disabling several tasks (like runIde) for the subprojects as gradle-intellij-plugin runs them on all subprojects otherwise. This has effects like causing runIde to open the IDE for each subproject, rather than just the main project. See https://github.com/rhdunn/xquery-intellij-plugin/blob/master/build.gradle#L102.

Q: Is buildSearchableOptions only indented to be run against the main top-level project?

[zolotov]

This has effects like causing runIde to open the IDE for each subproject, rather than just the main project.

This is not the effect of disabling of any task, it sounds like you run runIde for every subproject. To run it for root project only you should use :runIde task

[zolotov]

Q: Is buildSearchableOptions only indented to be run against the main top-level project?

buildSearchableOptions is intended to be run against on any project you run buildPlugin against.

[zolotov]

https://travis-ci.org/rhdunn/xquery-intellij-plugin/jobs/539671597#L235

$ ./gradlew assemble

I really doubt you want to run this command. It literally means "run assemble task and all dependent tasks on each project", it's weird to run all tasks and then disable them for subprojects. I'd suggest you need ./gradlew :assemble instead

    // The IntelliJ gradle plugin adds the tasks for all subprojects. This
    // does not make sense, and causes issues like performing the runIde
    // task once for each subproject.

Come on, you have applied gradle-intellij-plugin to all subprojects on line 63, of course, it added runIde task to each of them, why would it behave differently?

[rhdunn]

Thanks for your suggestions regarding using :assemble and :runIde -- I wasn't aware of these.

I am applying gradle-intellij-plugin to each subproject so they have the correct IntelliJ SDK classpaths and modules included. I've changed the comment to:

    // Using the IntelliJ gradle plugin to provide the IntelliJ platform SDK in
    // each subproject results in various deployment related tasks being added
    // to those subprojects. As this plugin only uses those tasks on the main
    // project, those tasks are disabled globally and only enabled for the
    // main project.

[zolotov]

The error looks legit to me. You have disabled prepareSandbox task for subproject but run buildSearchableOptions (which depends on prepareSandbox) on it. What do you think should be changed in the plugin exactly?

[rhdunn]

It would make sense to skip buildSearchableOptions if pluginSandbox is skipped. Failing that, an error message that prepareSandbox is needed for buildSearchableOptions.

[zolotov]

It would make sense to skip buildSearchableOptions if pluginSandbox is skipped.

It depends on it. Silently skipping task because its dependency is not satisfied doesn't seem a good idea to me, sorry.

[zolotov]

From my perspective, it looks like you have broke tasks-flow for the project you didn't want to run buildSearchableOptions, and you expect the plugin will help you with this breakage by further changing tasks flow. It might be implemented but I don't think plugin should handle such cases. The plugin gives you convenient defaults. I believe that If you started to modify the project model and tasks flow, you should handle the consequences by your own. If you can't face the consequences, don't break the defaults.