VS
Gradle не специфицирует порядок инициализации проектов (за исключением того, что root всегда конфигурируется первым)
Size: a a a
2020 May 11
VS
Таска есть. Резальтата может не быть, но вы делаете зависимость. А зависимость гарантирует, что результаты зависимости будут вычислены до зависимого. В этом весь смысл градла
Откуда таска возьмётся-то?
Порядок project evaluation не определён
Порядок project evaluation не определён
AN
Gradle не специфицирует порядок инициализации проектов (за исключением того, что root всегда конфигурируется первым)
Инициализация тут не причем. Порядок выполнения еще как специализирует.
VS
Инициализация тут не причем. Порядок выполнения еще как специализирует.
Таска создаётся в момент применения плагинов.
Порядок «применения плагинов к разным проектам» не определён
Порядок «применения плагинов к разным проектам» не определён
AN
Там используется контейнер для таски, который выполняется на второй фазе конфигурирования
AN
Порядок применения плагинов - да. Но таски по имени можно вызывать в любой момент. Они не сразу актуализируются.
VS
Порядок применения плагинов - да. Но таски по имени можно вызывать в любой момент. Они не сразу актуализируются.
Прости, но ты не прав
AN
Прав. Я на градле несколько бродячих животных съел. И то, что написано совершенно точно работает
VS
Прав. Я на градле несколько бродячих животных съел. И то, что написано совершенно точно работает
Работает != ты прав
AN
Работает != ты прав
Таски по имени резолвятся ленивым образом
AN
Весь градл на таких зависимостях построен. Если бы их не было, вообще бы межмодульного взаимодействия не было бы.
VS
Весь градл на таких зависимостях построен. Если бы их не было, вообще бы межмодульного взаимодействия не было бы.
И тут ты снова неправ.
Единственно надёжный способ на текущий момент — это configurations.
Единственно надёжный способ на текущий момент — это configurations.
VS
Весь градл на таких зависимостях построен. Если бы их не было, вообще бы межмодульного взаимодействия не было бы.
https://docs.gradle.org/current/javadoc/org/gradle/api/Project.html
>Finally, evaluate each Project by executing its "build.gradle" file, if present, against the project. The projects are evaluated in breadth-wise order, such that a project is evaluated before its child projects. This order can be overridden by calling evaluationDependsOnChildren() or by adding an explicit evaluation dependency using evaluationDependsOn(String).
>Finally, evaluate each Project by executing its "build.gradle" file, if present, against the project. The projects are evaluated in breadth-wise order, such that a project is evaluated before its child projects. This order can be overridden by calling evaluationDependsOnChildren() or by adding an explicit evaluation dependency using evaluationDependsOn(String).
AN
https://docs.gradle.org/current/javadoc/org/gradle/api/Project.html
>Finally, evaluate each Project by executing its "build.gradle" file, if present, against the project. The projects are evaluated in breadth-wise order, such that a project is evaluated before its child projects. This order can be overridden by calling evaluationDependsOnChildren() or by adding an explicit evaluation dependency using evaluationDependsOn(String).
>Finally, evaluate each Project by executing its "build.gradle" file, if present, against the project. The projects are evaluated in breadth-wise order, such that a project is evaluated before its child projects. This order can be overridden by calling evaluationDependsOnChildren() or by adding an explicit evaluation dependency using evaluationDependsOn(String).
В данный момент совершенно нет возможности спорить. Мой пример работает в любом случае потому что там обе таски в одном мпп модуле. По поводу примера Ильи можно пойти в @kotlin_js и спросить у него.
AN
https://docs.gradle.org/current/javadoc/org/gradle/api/Project.html
>Finally, evaluate each Project by executing its "build.gradle" file, if present, against the project. The projects are evaluated in breadth-wise order, such that a project is evaluated before its child projects. This order can be overridden by calling evaluationDependsOnChildren() or by adding an explicit evaluation dependency using evaluationDependsOn(String).
>Finally, evaluate each Project by executing its "build.gradle" file, if present, against the project. The projects are evaluated in breadth-wise order, such that a project is evaluated before its child projects. This order can be overridden by calling evaluationDependsOnChildren() or by adding an explicit evaluation dependency using evaluationDependsOn(String).
Вот, нашел место в доке:
"The task dependencies declared via task path are supported and cause relevant projects to be configured. Example: someTask.dependsOn(":someOtherProject:someOtherTask")"
"The task dependencies declared via task path are supported and cause relevant projects to be configured. Example: someTask.dependsOn(":someOtherProject:someOtherTask")"
AN
Вызов
project(":client") тоже конфигурирует зависимый проектVS
Это другое
VS
someTask(String) да, работает
VS
а вот project(«другой проект»).tasks(…) — может запросто упасть
AN
а вот project(«другой проект»).tasks(…) — может запросто упасть
Надо лезть в доку, но по-моему все-таки выов функции project конфигурирует