Какова цель Gradle?

Я мог бы немного помочь понять концепции Gradle (плагин v 0.7) в контексте Android Studio 0.4.0. Я раньше не использовал Gradle, и это вызывало у меня ничего, кроме проблем. Я не вижу его цели / выгоды, потому что я не знаю достаточно об этом.

Некоторые конкретные вопросы, которые я имею

  1. Каковы эти зависимости? Я делаю простое приложение с навигационным ящиком, ориентированным на API 11+, где он должен поддерживаться изначально. Какие зависимости я могу использовать?

  2. Что такое оболочка Gradle? Какие изменения, если таковые имеются, внесены в заполненное приложение?

  3. Почему Gradle нужно постоянно в сети? Когда я нахожусь на работе, у меня нет доступа к Интернету на моем личном ноутбуке. Понятно, что я не могу запустить или проверить свое приложение, потому что Gradle не может разрешить какой-либо ресурс без доступа в Интернет.

  4. Почему важно, чтобы Gradle использовал Groovy? Я искал в Интернете, и, как правило, это что-то вроде Gradle, но они обычно не объясняют, почему Groovy важен или что он делает для Android-приложения.

Иногда это сложно, как промежуточный программист, поскольку информация имеет тенденцию быть слишком простой или слишком сложной. Помимо моих конкретных вопросов, любая дополнительная информация, которую вы можете предоставить, была бы полезна. Я не собираюсь обсуждать плюсы и минусы Gradle и других инструментов, которые могут сделать то же самое, я просто хотел бы узнать больше о Gradle и его использовании, чтобы я мог принимать обоснованные решения.

благодаря

Solutions Collecting From Web of "Какова цель Gradle?"

Некоторые из ваших вопросов являются общими в том, что они говорят о том, почему инструменты сборки – это хорошо, как общий вопрос. Другие попадают в Gradle специально. Я постараюсь как можно более красноречиво рассмотреть обе категории, пытаясь избежать другой терминологии.

Инструменты сборки, такие как Maven, Gradle, SBT, Leiningen и т. Д., Помогают автоматизировать задачи, которые в противном случае мы могли бы выполнить вручную или «вручную автоматизировать». Я использую последнее, чтобы описать, что я использовал для Ant-записи пользовательских задач для компиляции, запуска, создания Javadoc и т. Д., Чтобы задачи могли быть автоматизированы в будущем. Соглашаясь с конвенциями, первоначально определенными Maven и принятыми другими впоследствии (например, поместите свой источник в src / main / java ), это становится возможным. Если я следую соглашениям, инструмент сборки может компилировать, запускать, генерировать Javadoc, test и все остальное с минимальной дополнительной работой.

Теперь на ваши вопросы (по порядку):

  1. Еще одна важная функция инструментов сборки – уменьшить «jar hell», последовательно управляя зависимостями между сборками. Я просто указываю, какую версию Apache Commons или Google Guava или Spring или Jackson я хочу (или даже диапазон версий), и инструмент сборки загрузит их и поместит их где-нибудь, чтобы они могли быть в пути к классам и в сборке, если это применимо (например, Военный файл). Я также могу определить области действия – например, я хочу, чтобы эта зависимость была доступна во время компиляции, а другая – только во время выполнения. Должен ли я предоставить его явно, или он будет доступен? Вроде того.
  2. Это особенность Gradle. Как описано здесь , оболочка Gradle помогает командам запускать Gradle без необходимости вручную устанавливать Gradle, а также поддерживать согласованность. Каждый использует ту же версию. После того, как вы его настроите, вам никогда не придется беспокоиться об этом, и все задачи Gradle, которые вы хотите использовать, доступны через оболочку, поэтому вам не нужно даже беспокоиться о том, что она есть. Вы можете установить Gradle напрямую и запустить его напрямую, но я редко вижу точку.
  3. Это общее. Ранее я упомянул об управлении зависимостями. Чтобы получить эти зависимости, инструмент сборки должен получить доступ в Интернет, где они доступны из Maven Central или кучей сторонних репозиториев. Еще одно новшество Maven, принятое другими, – это управление репозиториями , поэтому скомпилированные артефакты публикуются в хранилище в соответствии с конвенцией, поэтому другие проекты могут их использовать. Обычно вам это неинтересно. Вы просто говорите инструменту, что вам нужна определенная зависимость, и он знает, как его схватить, потому что все следуют соглашениям. В ситуациях, когда у вас нет доступа к Интернету (что-то, с чем я знаком), ваши варианты – просто захватить все зависимости, когда вы находитесь в сети, а затем, возможно, настроить локальный репозиторий Maven, такой как Nexus или Artifactory, для публикации этих артефактов. Затем вы указываете свой инструмент построения, чтобы посмотреть там, а также Maven Central и т. Д.
  4. Maven сконфигурирован с XML, и в то время это казалось действительно крутым. Но есть два последствия. Первая конфигурация становится очень многословной. Другой заключается в том, что становится сложно делать обычай. Вы должны сделать все декларативно в XML, что многие считают болью. Вы настраиваете плагины в XML, или пишете свои собственные и обертываете их так, как Maven может понять и может быть настроен в XML. Гораздо проще и мощнее выполнять сбор данных в коде. Gradle выбрала Groovy для этого, потому что Groovy делает для приятных DSL и очень легко учиться для разработчиков Java, поступающих из Maven. SBT выбрала Scala, а Leiningen выбрала Clojure, потому что эти инструменты сборки ориентированы на эти языки / платформы, поэтому разработчику Scala, например, не нужно ничего научиться использовать SBT, кроме DSL. Но более общий вывод заключается в том, что использование кода, а не XML имеет большую выгоду.

Надеюсь, это поможет.

Каковы эти зависимости?

Есть так много классных библиотек, которые вы могли бы использовать. И многие из этих библиотек теперь поддерживают интеграцию с gradle. Поэтому больше не нужно импортировать проект и размещать его самостоятельно. Все размещено на mavencentral. Вам по-прежнему нужна библиотека поддержки, даже если вы решили настроить таргетинг на API 11+.

Что такое оболочка Gradle?

Обертка градиентов – отличный инструмент, если вы работаете в команде или, особенно, в проекте с открытым исходным кодом. Вам не нужно устанавливать градуировку. Обертка градиента будет загружать и кэшировать все свои зависимости при первом запуске. Таким образом, все разработчики в вашей команде могут быстро построить проект.

Почему Gradle нужно постоянно в сети?

Потому что зависимости нужно синхронизировать. Вам повезло, если вы используете Android Studio. Последняя версия поддерживает «режим безградиентного режима».

Из примечаний к выпуску :

Studio теперь поддерживает режим Gradle Offline. Это полезно, если вы обнаружите себя без сетевого подключения, а ваши зависимости используют синтаксис плюс для получения последней доступной версии. В этом случае Gradle будет один раз в день (по умолчанию) подключиться к репозиторию артефактов, чтобы узнать, есть ли более новая версия. Если это сетевое подключение терпит неудачу, сборка завершится с ошибкой. Если у вас нет сетевого подключения, это проблематично. Теперь вы можете открыть параметры компилятора> Gradle и включить автономный режим, который заставит Gradle игнорировать проверки обновления до даты:

Режим безградиентного режима

Почему важно, чтобы Gradle использовал Groovy?

Вы пишете плагины градиента в Groovy. И все ваши задачи градации в build.gradle.


Осторожно: я не специалист по градле. На самом деле относительно новый пользователь.

Я понимаю, что все говорят о том, зачем нужна онлайн-часть Gradle, но для тех из нас, кто находится за брандмауэрами на работе, или когда мы можем работать в автономном режиме, это действительно ставит нагрузку на нас, чтобы выходить в интернет хотя бы один раз Для возможности компиляции в автономном режиме.

Я просто не понимаю, почему это требование относится к проекту. Что делать, если я начинаю совершенно новый проект в Android Studio, с которым я хочу протестировать концепцию? Я не могу это сделать, если я не в сети, по крайней мере, один раз. Что делать, если у меня нет доступа к Интернету в то время и вы хотите это сделать? Что тогда?

Похоже на ненужное требование, которое обременяет разработчика ненужными проблемами, которых можно было бы избежать. Опять же, я понимаю причину этого, но все же, чтобы заставить требование, по крайней мере, компилировать один раз в сети, чтобы использовать офлайн, кажется немного смешным.

Я хочу использовать Gradle, но на данный момент это то, что мы даже не можем использовать на работе из-за онлайн-требований. Мне нужно будет работать с нашим отделом безопасности, чтобы определить, какие дыры ударить в нашем брандмауэре, чтобы это разрешить, а также правильно настроить наш прокси-сервер, чтобы это разрешить.

Поэтому в настоящее время я не могу рекомендовать Gradle для использования на моем месте работы, а это значит, что мы также продолжим использовать Eclipse для разработки Android, а не Android Studio. Похоже, это предельное требование, которое не кажется необходимым.

Предположим, что понимание следующих пунктов является сложной основой:

  1. Что такое классы, интерфейсы, API, пакеты, модули и библиотеки.

  2. Каковы зависимости от модулей и что означает «управление зависимостями».

  3. Сложность современных приложений. Даже если вы сделаете простое приложение «Hello, world» (будь то настольное приложение или веб-приложение), оно должно включать десятки (если не сто) различных библиотек. Все эти библиотеки предоставляют инфраструктуру вашему приложению, но многие из них напрямую не связаны с ее логикой.

  4. Если ваше приложение не является «Hello, world», то скрыть его сложность (путем правильной модуляции) и автоматизировать его сборку и тестирование (с помощью правильных инструментов сборки) становится решающим фактором успеха.

С учетом этого понимания (и принимая во внимание драгоценные соображения, перечисленные уважаемыми коллегами выше), имеет смысл начать говорить о градиенте, муравье, плющом и maven.