Какова цель Gradle?
Я мог бы немного помочь понять концепции Gradle(плагин v 0.7) в контексте Android Studio 0.4.0. Я не использовал Gradle раньше, и это не вызывает у меня ничего, кроме проблем. Я не вижу его цели / выгоды, потому что я не знаю достаточно об этом.
У меня есть конкретные вопросы
Каковы эти зависимости? Я делаю простое приложение с навигационной панелью, ориентированной на API 11+, где оно должно быть изначально поддержано. Какие зависимости я могу использовать?
Что такое обертка Gradle? Какие изменения вносятся в заполненную заявку?
Почему Gradle должен быть постоянно онлайн? У меня нет доступа в интернет на моем личном ноутбуке, когда я на работе. Дошло до того, что я не могу запустить или протестировать свое приложение, потому что Gradle не может разрешить какой-либо ресурс без доступа в интернет.
Почему важно, чтобы Gradle использовал Groovy? Я искал в интернете, и это, как правило, нравится людям в Gradle, но они обычно не объясняют, почему Groovy важен или что он делает для приложения для Android.
Иногда это сложно, как программист среднего уровня, так как информация имеет тенденцию быть слишком простой или слишком сложной. Помимо моих конкретных вопросов, любая дополнительная информация, которую вы можете предоставить, будет полезна. Я не собираюсь обсуждать плюсы и минусы Gradle против других инструментов, которые могут делать то же самое, я просто хотел бы узнать больше о Gradle и его использовании, чтобы я мог принимать обоснованные решения.
Спасибо
4 ответа
Некоторые из ваших вопросов являются общими в том смысле, что они говорят о том, почему инструменты сборки являются хорошей вещью в целом. Другие попадают в Gradle специально. Я постараюсь рассмотреть обе категории как можно более кратко, стараясь избежать придирчивой терминологии других.
Инструменты сборки, такие как Maven, Gradle, SBT, Leiningen и т. Д., Помогают автоматизировать задачи, которые в противном случае пришлось бы выполнять вручную или "вручную". Я использую последний для описания того, что я делал с Ant для написания пользовательских задач для компиляции, запуска, генерации Javadoc и т. Д., Чтобы задачи можно было автоматизировать в будущем. Это становится возможным благодаря соответствию соглашениям, изначально определенным Maven и принятым другими (например, размещение вашего источника в src / main / java). Если я следую соглашениям, инструмент сборки может скомпилировать, запустить, сгенерировать Javadoc, протестировать и все остальное с минимальной дополнительной работой.
Теперь к вашим вопросам (по порядку):
- Другая важная функция инструментов сборки заключается в уменьшении "адского шума" путем согласованного управления зависимостями между сборками. Я просто указываю, какую версию Apache Commons или Google Guava, Spring или Jackson я хочу (или даже диапазон версий), и инструмент сборки будет загружать их и размещать где-нибудь, чтобы они могли быть в classpath и в сборке, если применимо (например, файл войны). Я также могу определить области действия - например, я хочу, чтобы эта зависимость была доступна во время компиляции, а другая - только во время выполнения. Нужно ли предоставлять это явно, или это будет доступно? Вроде того.
- Это специфично для Gradle. Как описано здесь, оболочка Gradle помогает командам запускать Gradle без необходимости вручную устанавливать Gradle, сохраняя при этом согласованность. Каждый использует одну и ту же версию. После того, как вы его настроите, вам больше не придется об этом беспокоиться, и все задачи Gradle, которые вы хотите использовать, доступны через оболочку, поэтому вам даже не нужно заботиться о том, что она есть. Вы можете установить Gradle напрямую и запустить его напрямую, но я редко вижу в этом смысл.
- Это вообще. Я упоминал об управлении зависимостями ранее. Чтобы получить эти зависимости, инструменту сборки необходимо подключиться к сети, где они доступны из Maven Central или из сторонних репозиториев. Другим нововведением Maven, принятым другими, является управление хранилищем, поэтому скомпилированные артефакты публикуются в хранилище в соответствии с соглашением, чтобы другие проекты могли их использовать. Обычно тебя это не волнует. Вы просто указываете инструменту, что вам нужна определенная зависимость, и он знает, как ее получить, потому что все следуют соглашениям. В ситуациях, когда у вас нет доступа к Интернету (с чем я хорошо знаком), вы можете просто захватить все зависимости, когда вы находитесь в сети, а затем при желании настроить локальный репозиторий Maven, такой как Nexus или Artifactory, для публикации этих артефактов. Затем вы указываете свой инструмент для сборки там, а также в Maven Central и т. Д.
- 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 - это отличный инструмент, если вы работаете в команде или особенно над проектом с открытым исходным кодом. Вам не нужно устанавливать Gradle. Оболочка gradle загрузит и кеширует все свои зависимости при первом запуске. Таким образом, все разработчики в вашей команде могут построить проект очень быстро.
Почему Gradle должен быть постоянно онлайн?
Потому что зависимости должны быть синхронизированы. Вам повезло, если вы используете Android Studio, хотя. Последняя версия поддерживает "автономный режим Gradle".
Из примечаний к выпуску:
Studio теперь поддерживает автономный режим Gradle. Это полезно, если вы оказались без сетевого подключения, и ваши зависимости используют синтаксис "плюс" для выбора последней доступной версии. В этом случае Gradle будет подключаться к хранилищу артефактов один раз в день (по умолчанию), чтобы узнать, есть ли более свежая версия. Если это сетевое соединение не удалось, сборка не удалась. Если у вас нет сетевого подключения, это проблематично. Теперь вы можете открыть "Компилятор"> "Параметры Gradle" и включить автономный режим, который скажет Gradle игнорировать проверки обновления:
Почему важно, чтобы Gradle использовал Groovy?
Вы пишете Gradle плагины в Groovy. И все ваши задачи на gradle в build.gradle.
Осторожно: я не специалист по грейду. На самом деле относительно новый пользователь, а также.
Я понимаю, что все говорят о том, почему онлайн-часть Gradle необходима, но для тех из нас, кто работает за брандмауэрами на работе или когда мы можем работать в автономном режиме, нам действительно нужно браться за выход в сеть хотя бы раз чтобы иметь возможность компилировать в автономном режиме.
Я просто не понимаю, почему это требование предъявляется к проекту. Что, если я запускаю совершенно новый проект в Android Studio, с которым я хочу протестировать концепцию? Я не смогу сделать это, пока я не буду онлайн хотя бы раз. Что если у меня нет доступа к интернету в это время, и я хочу это сделать? Что тогда?
Похоже на ненужное требование, которое обременяет разработчика ненужными проблемами, которых можно избежать. Опять же, я понимаю причину этого, но все же принудительно требовать хотя бы один раз компиляции в сети, чтобы использовать оффлайн, кажется немного нелепым.
Я хочу использовать Gradle, но на данный момент это то, что мы даже не можем использовать на работе из-за требований онлайн. Мне нужно будет поработать с нашим отделом безопасности, чтобы определить, какие дыры необходимо пробить в нашем брандмауэре, чтобы это было возможно, а также правильно настроить наш прокси-сервер, чтобы разрешить это.
Поэтому в настоящее время я не могу рекомендовать Gradle для использования по месту работы, а это значит, что мы также продолжим использовать Eclipse для разработки Android, а не Android Studio. Похоже, ограничивающее требование, которое не кажется необходимым.
Предположим, что понимание следующих пунктов служит совокупной основой:
Что такое классы, интерфейсы, API, пакеты, модули и библиотеки.
Что такое модульные зависимости и что означает "управление зависимостями".
Сложность современных приложений. Даже если вы создаете простое приложение "Hello, world" (будь то настольное приложение или веб-приложение), оно должно включать в себя дюжину (если не сотню) различных библиотек. Все эти библиотеки обеспечивают инфраструктуру для вашего приложения, но многие из них не имеют прямого отношения к его логике.
Если ваше приложение не "Hello, world", то сокрытие его сложности (путем правильной модульности) и автоматизация его сборки и тестирования (с использованием надлежащих инструментов сборки) становится критически важным для успеха.
Имея это в виду (и принимая во внимание драгоценные соображения, перечисленные выше уважаемыми коллегами), имеет смысл начать говорить град, муравей, плющ и мавен.