#gradle #windows-subsystem-for-linux
#gradle #windows-subsystem-for-linux
Вопрос:
У меня есть проект с buildSrc, в котором есть пакет (например abc ).
Я использую этот пакет в других моих build.gradle файлах проекта (например abc.test() ). Учитывая, что он находится под buildSrc управлением, он импортируется автоматически, и он работает на моем macbook.
Сейчас я пытаюсь сделать то же самое с Windows WSL.
Моя текущая настройка предполагает установку java и gradle в Windows (и работу через Android Studio), а также установку java и gradle в WSL. Короче говоря, gradle WSL продолжал жаловаться на неправильные пути java_home, когда они были общими, поэтому я установил все, как если бы это был чистый Linux.
При попытке запуска gradle build команда теперь жалуется:
> Could not get unknown property 'abc' for object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.
Есть ли способ обойти это? Есть ли лучший обходной путь для запуска задач gradle из WSL? Я использую это в предварительной фиксации, поэтому я даже открыт для запуска команды «через Windows», если это поможет. На данный момент я подозреваю, что это проблема с путями, потому что команды сборки отлично работают в IDE.
Комментарии:
1. Есть ли вероятность, что какие-либо пути на основе Windows предшествуют путям Linux в переменных среды (либо $PATH, либо $JAVA_HOME, либо что-либо еще)? Когда установлены обе версии инструмента для Windows и Linux, часто путь Windows будет иметь приоритет над версией Linux, что вызывает проблемы. Похоже, что так оно и есть.
2. Я исправил проблему JAVA_HOME, установив ее в Linux и установив в zsh (который устанавливается после и является тем, который я хочу). Проблема сейчас заключается в том, что файлы gradle не разрешаются должным образом, когда они должны работать. Я не уверен, связано ли это с тем, что gradle не знает папку проекта, или это какая-то другая проблема с путями