Explicitly disable dev/prod tasks based on flag

[malliaridis]

Description

With the production build flag set to false, gradle may fail when running gradlew assemble with an error due to some invalid task dependencies coming from the Compose MP plugin. The reported message is similar to the below:

See also discussion in https://lists.apache.org/thread/1l25p9cd9h8ch32jt2ljpmdt3fc9bctq

...
> Task :solr:ui:wasmJsProductionExecutableCompileSync FAILED

FAILURE: Build failed with an exception.

* What went wrong:
A problem was found with the configuration of task ':solr:ui:wasmJsProductionExecutableCompileSync' (type 'DefaultIncrementalSyncTask').
  - Gradle detected a problem with the following location: '/Users/christos/workspace/apache/solr/build/js/packages/composeApp/kotlin'.
    
    Reason: Task ':solr:ui:wasmJsBrowserDevelopmentWebpack' uses this output of task ':solr:ui:wasmJsProductionExecutableCompileSync' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.
    
    Possible solutions:
      1. Declare task ':solr:ui:wasmJsProductionExecutableCompileSync' as an input of ':solr:ui:wasmJsBrowserDevelopmentWebpack'.
      2. Declare an explicit dependency on ':solr:ui:wasmJsProductionExecutableCompileSync' from ':solr:ui:wasmJsBrowserDevelopmentWebpack' using Task#dependsOn.
      3. Declare an explicit dependency on ':solr:ui:wasmJsProductionExecutableCompileSync' from ':solr:ui:wasmJsBrowserDevelopmentWebpack' using Task#mustRunAfter.
    
    For more information, please refer to https://docs.gradle.org/8.10/userguide/validation_problems.html#implicit_dependency in the Gradle documentation.

The error is likely thrown because by default both development and production artifacts are generated on assemble. In the webapp module, we explicitly depend on tasks and include their outputs based on the variant configured by the production flag, leading to potentially different artifacts being included based on execution order.

The current workaround was to set the production flag to true.

Solution

This PR solves the issue of the invalid task dependencies and allows the production flag to be set to false again without failing on gradlew assemble.

The production flag can be set to false again on our build servers after merging this.

Tests

No tests written for gradle execution

Checklist

Please review the following and check all that apply:

• I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
• I have created a Jira issue and added the issue ID to my pull request title.
• I have given Solr maintainers access to contribute to my PR branch. (optional but recommended, not available for branches on forks living under an organisation)
• I have developed this patch against the main branch.
• I have run ./gradlew check.
• I have added tests for my changes.
• I have added documentation for the Reference Guide

[malliaridis]

@gerlowskija I've added you as a reviewer as you have reported this issue on slack.

[dsmiley]

So these tasks like wasmJsProductionExecutableCompileSync are not defined by our project but are defined by external plugins we use, which have the notion of "production" artifacts and maybe "development" artifacts as well? And that which are mutually exclusive?

(just asking/stating this for confirmation)

[malliaridis]

So these tasks like wasmJsProductionExecutableCompileSync are not defined by our project but are defined by external plugins we use, which have the notion of "production" artifacts and maybe "development" artifacts as well?

Yes, that's what I could figure out from the gradle tasks outputed with --dry-run.

And that which are mutually exclusive?

I believe so, yes. During assemble, both development and production tasks are executed and artifacts are generated in that order, so that production override the development artifacts. However, when we assemble with our custom gradle flag production=false, we include and depend on artifacts from the development. In my understanding, this is causing the error.