Gradle-проекты по умолчанию используют ту же структуру каталогов, что и Maven:
src/main/java – исходники
src/main/resources – ресурсы
src/test/java – тесты
src/test/resources – ресурсы тестов
(и т.д., при наличии других sourceSets)
Выходные файлы и артефакты – в директории build/ (аналог Maven target/).
Gradle принял мавеновские соглашения, поэтому проекты можно легко переключать между Maven и Gradle без изменения структуры. Дополнительно Gradle создает в корне скрипты Wrapper:
gradlew, gradlew.bat – запуск Gradle с конкретной версией.
gradle/wrapper/gradle-wrapper.properties – указывает версию Gradle для проекта (и URL для скачивания дистрибутива).
gradle/wrapper/ – содержит jar самого wrapper.
Пояснение
Как отмечалось, Gradle наследует принципы Convention Over Configuration от Maven. При применении Java Plugin он настраивает проект ожидать такой же расклад, что и Maven. Поэтому, если вы конвертируете Maven-проект на Gradle, нет нужды перекладывать файлы – Gradle сразу обнаружит код и тесты.
Каталог build/ – аналог target – Gradle складывает туда все сгенерированные ресурсы:
build/classes/java/main – скомпилированные .class основной программы,
build/classes/java/test – классы тестов,
build/resources/main – скопированные ресурсы,
build/libs – итоговые JAR/WAR/ZIP файлы,
build/reports – отчеты (например, по тестам, coverage),
build/tmp – временные файлы,
build/generated – может появляться для сгенерированных источников и пр.
Gradle Wrapper файлы в структуре — это особенность Gradle-проектов: Maven-проекты обычно wrapper не включают (хотя можно), а Gradle-проекты почти всегда включают. Поэтому в репозитории вы увидите исполняемый файл gradlew. Его рекомендуется запускать для сборки.
Структура многомодульного Gradle-проекта: обычно выглядит так:
project-root/
├── build.gradle (может быть пуст, если логика в модульных скриптах, но часто содержит общие настройки)
├── settings.gradle (список модулей)
├── gradlew, gradlew.bat, gradle/wrapper/*
├── module1/
│ └── build.gradle (настроенный под конкретный модуль)
├── module2/
│ └── build.gradle
└── ... etc
Внутри каждого модуля – опять же src/main/java и т.д. для каждого.
Если проект – Android, там структура несколько иная (папка app/src/main/java и app/src/main/res), но Gradle настраивается плагином Android соответствующим.
Современные подходы: И Maven, и Gradle сходятся на единой стандартной структуре, что очень удобно. Разработчики могут без труда ориентироваться: код лежит в src/main, тесты в src/test. Если нужно добавить новые категории (например, интеграционные тесты), в Maven часто делают профиль + отдельные папки, а в Gradle – sourceSet + задачки, но место обычно тоже под src/integrationTest/java.
Отдельно стоит упомянуть, что Gradle позволяет легко включить в сборку проекты на других языках. Например, Kotlin/Scala – есть плагины kotlin, scala, они добавят соответствующие папки:
Для Kotlin – обычно тот же src/main/kotlin (или вместе с java в одном).
Для Scala – src/main/scala.
Но это уже частности.
Итого: Стандартная структура проекта в контексте Gradle полностью совпадает с Maven (кроме имени выходной папки). Это сделано специально, чтобы снижать порог входа и использовать наработанные практики организации кода.
Примечание: Если вдруг вы видите Gradle-проект с нестандартной структурой, значит, авторы явно переопределили sourceSets. Такое бывает редко и, как правило, не рекомендуется без необходимости, так как ломает ожидания и требует дополнительной поддержки. Следуя соглашениям, вы делаете проект понятным для любого Java-разработчика.
Gradle: Стандартная структура проекта
Gradle-проекты по умолчанию используют ту же структуру каталогов, что и Maven:
src/main/java – исходники
src/main/resources – ресурсы
src/test/java – тесты
src/test/resources – ресурсы тестов
(и т.д., при наличии других sourceSets)
Выходные файлы и артефакты – в директории build/ (аналог Maven target/).
Gradle принял мавеновские соглашения, поэтому проекты можно легко переключать между Maven и Gradle без изменения структуры. Дополнительно Gradle создает в корне скрипты Wrapper:
gradlew, gradlew.bat – запуск Gradle с конкретной версией.
gradle/wrapper/gradle-wrapper.properties – указывает версию Gradle для проекта (и URL для скачивания дистрибутива).
gradle/wrapper/ – содержит jar самого wrapper.
Пояснение
Как отмечалось, Gradle наследует принципы Convention Over Configuration от Maven. При применении Java Plugin он настраивает проект ожидать такой же расклад, что и Maven. Поэтому, если вы конвертируете Maven-проект на Gradle, нет нужды перекладывать файлы – Gradle сразу обнаружит код и тесты.
Каталог build/ – аналог target – Gradle складывает туда все сгенерированные ресурсы:
build/classes/java/main – скомпилированные .class основной программы,
build/classes/java/test – классы тестов,
build/resources/main – скопированные ресурсы,
build/libs – итоговые JAR/WAR/ZIP файлы,
build/reports – отчеты (например, по тестам, coverage),
build/tmp – временные файлы,
build/generated – может появляться для сгенерированных источников и пр.
Gradle Wrapper файлы в структуре — это особенность Gradle-проектов: Maven-проекты обычно wrapper не включают (хотя можно), а Gradle-проекты почти всегда включают. Поэтому в репозитории вы увидите исполняемый файл gradlew. Его рекомендуется запускать для сборки.
Структура многомодульного Gradle-проекта: обычно выглядит так:
project-root/
├── build.gradle (может быть пуст, если логика в модульных скриптах, но часто содержит общие настройки)
├── settings.gradle (список модулей)
├── gradlew, gradlew.bat, gradle/wrapper/*
├── module1/
│ └── build.gradle (настроенный под конкретный модуль)
├── module2/
│ └── build.gradle
└── ... etc
Внутри каждого модуля – опять же src/main/java и т.д. для каждого.
Если проект – Android, там структура несколько иная (папка app/src/main/java и app/src/main/res), но Gradle настраивается плагином Android соответствующим.
Современные подходы: И Maven, и Gradle сходятся на единой стандартной структуре, что очень удобно. Разработчики могут без труда ориентироваться: код лежит в src/main, тесты в src/test. Если нужно добавить новые категории (например, интеграционные тесты), в Maven часто делают профиль + отдельные папки, а в Gradle – sourceSet + задачки, но место обычно тоже под src/integrationTest/java.
Отдельно стоит упомянуть, что Gradle позволяет легко включить в сборку проекты на других языках. Например, Kotlin/Scala – есть плагины kotlin, scala, они добавят соответствующие папки:
Для Kotlin – обычно тот же src/main/kotlin (или вместе с java в одном).
Для Scala – src/main/scala.
Но это уже частности.
Итого: Стандартная структура проекта в контексте Gradle полностью совпадает с Maven (кроме имени выходной папки). Это сделано специально, чтобы снижать порог входа и использовать наработанные практики организации кода.
Примечание: Если вдруг вы видите Gradle-проект с нестандартной структурой, значит, авторы явно переопределили sourceSets. Такое бывает редко и, как правило, не рекомендуется без необходимости, так как ломает ожидания и требует дополнительной поддержки. Следуя соглашениям, вы делаете проект понятным для любого Java-разработчика.
src/main/java – исходники
src/main/resources – ресурсы
src/test/java – тесты
src/test/resources – ресурсы тестов
(и т.д., при наличии других sourceSets)
Выходные файлы и артефакты – в директории build/ (аналог Maven target/).
Gradle принял мавеновские соглашения, поэтому проекты можно легко переключать между Maven и Gradle без изменения структуры. Дополнительно Gradle создает в корне скрипты Wrapper:
gradlew, gradlew.bat – запуск Gradle с конкретной версией.
gradle/wrapper/gradle-wrapper.properties – указывает версию Gradle для проекта (и URL для скачивания дистрибутива).
gradle/wrapper/ – содержит jar самого wrapper.
Пояснение
Как отмечалось, Gradle наследует принципы Convention Over Configuration от Maven. При применении Java Plugin он настраивает проект ожидать такой же расклад, что и Maven. Поэтому, если вы конвертируете Maven-проект на Gradle, нет нужды перекладывать файлы – Gradle сразу обнаружит код и тесты.
Каталог build/ – аналог target – Gradle складывает туда все сгенерированные ресурсы:
build/classes/java/main – скомпилированные .class основной программы,
build/classes/java/test – классы тестов,
build/resources/main – скопированные ресурсы,
build/libs – итоговые JAR/WAR/ZIP файлы,
build/reports – отчеты (например, по тестам, coverage),
build/tmp – временные файлы,
build/generated – может появляться для сгенерированных источников и пр.
Gradle Wrapper файлы в структуре — это особенность Gradle-проектов: Maven-проекты обычно wrapper не включают (хотя можно), а Gradle-проекты почти всегда включают. Поэтому в репозитории вы увидите исполняемый файл gradlew. Его рекомендуется запускать для сборки.
Структура многомодульного Gradle-проекта: обычно выглядит так:
project-root/
├── build.gradle (может быть пуст, если логика в модульных скриптах, но часто содержит общие настройки)
├── settings.gradle (список модулей)
├── gradlew, gradlew.bat, gradle/wrapper/*
├── module1/
│ └── build.gradle (настроенный под конкретный модуль)
├── module2/
│ └── build.gradle
└── ... etc
Внутри каждого модуля – опять же src/main/java и т.д. для каждого.
Если проект – Android, там структура несколько иная (папка app/src/main/java и app/src/main/res), но Gradle настраивается плагином Android соответствующим.
Современные подходы: И Maven, и Gradle сходятся на единой стандартной структуре, что очень удобно. Разработчики могут без труда ориентироваться: код лежит в src/main, тесты в src/test. Если нужно добавить новые категории (например, интеграционные тесты), в Maven часто делают профиль + отдельные папки, а в Gradle – sourceSet + задачки, но место обычно тоже под src/integrationTest/java.
Отдельно стоит упомянуть, что Gradle позволяет легко включить в сборку проекты на других языках. Например, Kotlin/Scala – есть плагины kotlin, scala, они добавят соответствующие папки:
Для Kotlin – обычно тот же src/main/kotlin (или вместе с java в одном).
Для Scala – src/main/scala.
Но это уже частности.
Итого: Стандартная структура проекта в контексте Gradle полностью совпадает с Maven (кроме имени выходной папки). Это сделано специально, чтобы снижать порог входа и использовать наработанные практики организации кода.
Примечание: Если вдруг вы видите Gradle-проект с нестандартной структурой, значит, авторы явно переопределили sourceSets. Такое бывает редко и, как правило, не рекомендуется без необходимости, так как ломает ожидания и требует дополнительной поддержки. Следуя соглашениям, вы делаете проект понятным для любого Java-разработчика.
Автор: к.п.н., Румянцев Сергей Александрович, доцент Финансового университета при Правительстве РФ; доцент ОЧУВО Международного инновационного университета; Консалтинг, управление разработкой ПО; системный и бизнес анализ; менеджмент; аналитиз данных; управление ИТ. Телефон для связи +79269444818 (мессенджеры)
Короткая ссылка:
Gradle-проекты по умолчанию используют ту же структуру каталогов, что и Maven:
src/main/java – исходники
src/main/resources – ресурсы
src/test/java – тесты
src/test/resources – ресурсы тестов
(и т.д., при наличии других sourceSets)
Выходные файлы и артефакты – в директории build/ (аналог Maven target/).
Gradle принял мавеновские соглашения, поэтому проекты можно легко переключать между Maven и Gradle без изменения структуры. Дополнительно Gradle создает в корне скрипты Wrapper:
gradlew, gradlew.bat – запуск Gradle с конкретной версией.
gradle/wrapper/gradle-wrapper.properties – указывает версию Gradle для проекта (и URL для скачивания дистрибутива).
gradle/wrapper/ – содержит jar самого wrapper.
Пояснение
Как отмечалось, Gradle наследует принципы Convention Over Configuration от Maven. При применении Java Plugin он настраивает проект ожидать такой же расклад, что и Maven. Поэтому, если вы конвертируете Maven-проект на Gradle, нет нужды перекладывать файлы – Gradle сразу обнаружит код и тесты.
Каталог build/ – аналог target – Gradle складывает туда все сгенерированные ресурсы:
build/classes/java/main – скомпилированные .class основной программы,
build/classes/java/test – классы тестов,
build/resources/main – скопированные ресурсы,
build/libs – итоговые JAR/WAR/ZIP файлы,
build/reports – отчеты (например, по тестам, coverage),
build/tmp – временные файлы,
build/generated – может появляться для сгенерированных источников и пр.
Gradle Wrapper файлы в структуре — это особенность Gradle-проектов: Maven-проекты обычно wrapper не включают (хотя можно), а Gradle-проекты почти всегда включают. Поэтому в репозитории вы увидите исполняемый файл gradlew. Его рекомендуется запускать для сборки.
Структура многомодульного Gradle-проекта: обычно выглядит так:
project-root/
├── build.gradle (может быть пуст, если логика в модульных скриптах, но часто содержит общие настройки)
├── settings.gradle (список модулей)
├── gradlew, gradlew.bat, gradle/wrapper/*
├── module1/
│ └── build.gradle (настроенный под конкретный модуль)
├── module2/
│ └── build.gradle
└── ... etc
Внутри каждого модуля – опять же src/main/java и т.д. для каждого.
Если проект – Android, там структура несколько иная (папка app/src/main/java и app/src/main/res), но Gradle настраивается плагином Android соответствующим.
Современные подходы: И Maven, и Gradle сходятся на единой стандартной структуре, что очень удобно. Разработчики могут без труда ориентироваться: код лежит в src/main, тесты в src/test. Если нужно добавить новые категории (например, интеграционные тесты), в Maven часто делают профиль + отдельные папки, а в Gradle – sourceSet + задачки, но место обычно тоже под src/integrationTest/java.
Отдельно стоит упомянуть, что Gradle позволяет легко включить в сборку проекты на других языках. Например, Kotlin/Scala – есть плагины kotlin, scala, они добавят соответствующие папки:
Для Kotlin – обычно тот же src/main/kotlin (или вместе с java в одном).
Для Scala – src/main/scala.
Но это уже частности.
Итого: Стандартная структура проекта в контексте Gradle полностью совпадает с Maven (кроме имени выходной папки). Это сделано специально, чтобы снижать порог входа и использовать наработанные практики организации кода.
Примечание: Если вдруг вы видите Gradle-проект с нестандартной структурой, значит, авторы явно переопределили sourceSets. Такое бывает редко и, как правило, не рекомендуется без необходимости, так как ломает ожидания и требует дополнительной поддержки. Следуя соглашениям, вы делаете проект понятным для любого Java-разработчика.
https://webprogr.ru/~GVgnn
src/main/java – исходники
src/main/resources – ресурсы
src/test/java – тесты
src/test/resources – ресурсы тестов
(и т.д., при наличии других sourceSets)
Выходные файлы и артефакты – в директории build/ (аналог Maven target/).
Gradle принял мавеновские соглашения, поэтому проекты можно легко переключать между Maven и Gradle без изменения структуры. Дополнительно Gradle создает в корне скрипты Wrapper:
gradlew, gradlew.bat – запуск Gradle с конкретной версией.
gradle/wrapper/gradle-wrapper.properties – указывает версию Gradle для проекта (и URL для скачивания дистрибутива).
gradle/wrapper/ – содержит jar самого wrapper.
Пояснение
Как отмечалось, Gradle наследует принципы Convention Over Configuration от Maven. При применении Java Plugin он настраивает проект ожидать такой же расклад, что и Maven. Поэтому, если вы конвертируете Maven-проект на Gradle, нет нужды перекладывать файлы – Gradle сразу обнаружит код и тесты.
Каталог build/ – аналог target – Gradle складывает туда все сгенерированные ресурсы:
build/classes/java/main – скомпилированные .class основной программы,
build/classes/java/test – классы тестов,
build/resources/main – скопированные ресурсы,
build/libs – итоговые JAR/WAR/ZIP файлы,
build/reports – отчеты (например, по тестам, coverage),
build/tmp – временные файлы,
build/generated – может появляться для сгенерированных источников и пр.
Gradle Wrapper файлы в структуре — это особенность Gradle-проектов: Maven-проекты обычно wrapper не включают (хотя можно), а Gradle-проекты почти всегда включают. Поэтому в репозитории вы увидите исполняемый файл gradlew. Его рекомендуется запускать для сборки.
Структура многомодульного Gradle-проекта: обычно выглядит так:
project-root/
├── build.gradle (может быть пуст, если логика в модульных скриптах, но часто содержит общие настройки)
├── settings.gradle (список модулей)
├── gradlew, gradlew.bat, gradle/wrapper/*
├── module1/
│ └── build.gradle (настроенный под конкретный модуль)
├── module2/
│ └── build.gradle
└── ... etc
Внутри каждого модуля – опять же src/main/java и т.д. для каждого.
Если проект – Android, там структура несколько иная (папка app/src/main/java и app/src/main/res), но Gradle настраивается плагином Android соответствующим.
Современные подходы: И Maven, и Gradle сходятся на единой стандартной структуре, что очень удобно. Разработчики могут без труда ориентироваться: код лежит в src/main, тесты в src/test. Если нужно добавить новые категории (например, интеграционные тесты), в Maven часто делают профиль + отдельные папки, а в Gradle – sourceSet + задачки, но место обычно тоже под src/integrationTest/java.
Отдельно стоит упомянуть, что Gradle позволяет легко включить в сборку проекты на других языках. Например, Kotlin/Scala – есть плагины kotlin, scala, они добавят соответствующие папки:
Для Kotlin – обычно тот же src/main/kotlin (или вместе с java в одном).
Для Scala – src/main/scala.
Но это уже частности.
Итого: Стандартная структура проекта в контексте Gradle полностью совпадает с Maven (кроме имени выходной папки). Это сделано специально, чтобы снижать порог входа и использовать наработанные практики организации кода.
Примечание: Если вдруг вы видите Gradle-проект с нестандартной структурой, значит, авторы явно переопределили sourceSets. Такое бывает редко и, как правило, не рекомендуется без необходимости, так как ломает ожидания и требует дополнительной поддержки. Следуя соглашениям, вы делаете проект понятным для любого Java-разработчика.
Короткая ссылка на новость:https://webprogr.ru/~GVgnn
Последние новости