Когда вы используете инструмент сборки, такой как Gradle (или maven), предполагается, что инструмент сборки отвечает за настройку таких вещей, как зависимости проекта и пути к классам.
Этот вид конфликтует с пользовательским интерфейсом Eclipse, который создан для того, чтобы вы могли управлять путем к классам/зависимостями через свой собственный пользовательский интерфейс.
Но пользовательский интерфейс Eclipse контролирует только то, что eclipse использует в качестве пути к классам, когда компилятор Eclipse JDT компилирует ваш код... внутри Eclipse.
Поэтому, если вы измените что-то таким образом, Gradle не будет знать об этих зависимостях, и сборка не будет работать.
Да, это определенно сбивает с толку :-)
Правильным будет полностью управлять своими зависимостями и конфигурацией проекта через gradle. Так что это означает редактирование build.gradle и settings.gradle.
Инструменты (BuildShip или STS Gradle Tools) предоставляют «мост» для попытки настройки проектов Eclipse в соответствии с вашей сборкой.
Например, они могут предложить команду «Обновить проект» или «Обновить зависимости» в контекстном меню проекта.
Даже если вы не используете инструменты Gradle, это верно. Затем вы должны использовать плагин Gradle «ecplise» и запустить команду, например
gradle cleanEclipse eclipse
Чтобы сгенерировать конфигурацию проекта eclipse из конфигурации сборки. Затем импортируйте проект в Eclipse в соответствии с настройками gradle. Кроме того, в этом случае было бы плохой идеей использовать пользовательский интерфейс Eclipse для внесения изменений в путь сборки, поскольку в конечном итоге он имеет ту же проблему, изменения, которые вы вносите в эти сгенерированные файлы, могут привести к компиляции внутри Eclipse, но Gradle не знает, что вы ничего не изменил. И в следующий раз, когда вы запустите gradle cleanEclipse eclipse, ваши изменения также будут утеряны.
Что касается ваших конкретных вопросов:
следует ли редактировать файлы settings.gradle или build.gradle вручную...
Да.
... без добавления зависимостей через графический интерфейс Eclipse...
Да.
... или оба должны использоваться одновременно?
Нет, настраивайте только в gradle. Затем «синхронизируйте его», чтобы затмить каким-либо инструментом (BuildShip/STS Gradle/gradle cleanEclipse eclipse)
Как это влияет на то, какие скрытые файлы должны индексироваться Git (.project, .classpath, .settings, .gradle)?
Общее правило. Индексируйте только то, что определяет поведение gradle (могут быть некоторые исключения, но в целом старайтесь свести их к минимуму, нарушая это правило, только если у вас есть веская причина).
Поэтому специально не добавляйте в git эти «метаданные затмения»
- .настройки
- .проект
- .класспуть
Поместите в git: оболочку gradle и файл ее свойств.
В Gradle также есть папка .gradle. Это относится к градиенту, а не к затмению, а к кешам и вещам, которые являются «временными». Вы также не хотите, чтобы они были в git.
person
Kris
schedule
22.07.2016
