Maven vs Gradle? Это неправильная постановка вопроса
Написать, наконец, этот пост меня заставила уже давняя дискуссия вот к этому посту на тему, которая время от времени всплывает то там, то тут.
Я много раз имел возможность убедиться, что далеко не все одинаково понимают, в чем же состоит декларативность vs процедурность той или иной системы сборки. Основным достоинством инструмента сборки зачастую считается возможность писать алгоритмы сборки на удобном языке. Нужен DSL, никуда без него.
В gradle этот DSL базируется на groovy. sbt использует скалу, leiningen — Clojure, Ant использует xml (совершенно не по делу, кстати). Несложно припомнить системы сборки на базе javascript. Каждый собирает на том языке, который ему ближе. И новые инструменты пишут, например, на котлине.
Увы, но наличие DSL совсем не означает декларативности. Скорее наоборот. В итоге, gradle проект вообще не может полноценно жить без pom.xml. Это шутка, но с большой долей правды. Посмотрите вот сюда: это репозиторий.
Что у нас тут лежит? Да-да, именно pom.xml, он самый. А где же у нас build.gradle? А нет его. Понимаете? Его тут нет.
То есть все метаданные, которые предоставлены о собранном проекте, который заметим, собирается при помощи gradle, состоят только и исключительно из метаданных maven.
Вас это не удивляет? Меня — нисколько. На мой взгляд, gradle, sbt, leiningen и многие другие инструменты почти (или вовсе) не предоставляют метаданных в доступном другим продуктам виде.
Они реально видны только самим себе, и только изнутри процесса сборки. Просто потому, что скрипт сборки — это груви код (Clojure, скала, javascript). Именно поэтому же их так плохо поддерживают IDE (в сравнении с maven или ant, где скрипт это xml). Чтобы понять, что там происходит, нужно выполнить. Нужно иметь gradle внутри, и нужно чтобы gradle отдавал в IDE необходимую информацию.
Как я вижу себе декларативность, и зачем она бывает нужна? В качестве иллюстрации приведу два своих проекта, и один от apache:
Во-первых, мы видим, что с описанием проекта (в моем случае это всегда был pom.xml) иногда бывает нужно и можно работать из любого достаточно развитого языка. Это не обязан быть инструмент сборки, на который изначально расчитан проект.
Во-вторых, если репозиторий спроектирован правильно, в соответствии с принципами REST, то нам не нужен никакой специальный софт для работы с ним, кроме http-сервера. Нужны только данные метауровня чуть выше проекта (список доступных версий, например).
В-третьих, очень удобно то, что важная часть инфраструктуры, в нашем случае plugins, сами просто обычные артефакты, лежат в том же репозитории, и никак не связаны вообще с конкретным проектом.
Вот это я называю декларативным подходом. У нас есть проекты, их много. Они бывают в репозитории, в виде собранных артефактов, в VCS, и еще где-либо, и могут обрабатываться разными инструментами — а не только одним единственным. Дескриптор проекта — это просто файл, любого стандартного и удобного для обработки формата. Репозиторий артефактов — это тоже стандартизованный формат + простой REST API. А логика сборки, на любом удобном вам DSL, лежит отдельно. Хотите — в самом дескрипторе, хотите — в репозитории.
Как бы я вообще это все сделал? В сущности, если брать за основу maven, то сейчас тут не хватает гибкости в части plugins, их настроек, и т.п., потому что существующий xml — это сериализованное представление java-модели данных plugins и ядра, и оно не гибко. Если разработчики решили, что какие-то данные о проекте вам не нужны — у вас остается только вариант key-value в виде properties.
А следовало бы сделать нечто произвольной, но регулярной структуры, ну скажем типа RDF (не обязательно именно его).
Описание проекта в виде RDF сразу позволяет делать полезные вещи вроде поиска в нем, как в базе данных (т.е. репозиторий, в части метаданных, становится просто SPARQL endpoint, и умеет отвечать на поисковые запросы). И такие же запросы можно строить применительно к проекту.
Вот это и был бы истинный poliglot maven. Причем это, кстати, выглядит вполне реализуемо, даже в рамках существующей инфраструктуры.
Maven vs Gradle? Это неправильная постановка вопроса
Написать, наконец, этот пост меня заставила уже давняя дискуссия вот к этому посту на тему, которая время от времени всплывает то там, то тут.
Я много раз имел возможность убедиться, что далеко не все одинаково понимают, в чем же состоит декларативность vs процедурность той или иной системы сборки. Основным достоинством инструмента сборки зачастую считается возможность писать алгоритмы сборки на удобном языке. Нужен DSL, никуда без него.
В gradle этот DSL базируется на groovy. sbt использует скалу, leiningen — Clojure, Ant использует xml (совершенно не по делу, кстати). Несложно припомнить системы сборки на базе javascript. Каждый собирает на том языке, который ему ближе. И новые инструменты пишут, например, на котлине.
Увы, но наличие DSL совсем не означает декларативности. Скорее наоборот. В итоге, gradle проект вообще не может полноценно жить без pom.xml. Это шутка, но с большой долей правды. Посмотрите вот сюда: это репозиторий.
Что у нас тут лежит? Да-да, именно pom.xml, он самый. А где же у нас build.gradle? А нет его. Понимаете? Его тут нет.
То есть все метаданные, которые предоставлены о собранном проекте, который заметим, собирается при помощи gradle, состоят только и исключительно из метаданных maven.
Вас это не удивляет? Меня — нисколько. На мой взгляд, gradle, sbt, leiningen и многие другие инструменты почти (или вовсе) не предоставляют метаданных в доступном другим продуктам виде.
Они реально видны только самим себе, и только изнутри процесса сборки. Просто потому, что скрипт сборки — это груви код (Clojure, скала, javascript). Именно поэтому же их так плохо поддерживают IDE (в сравнении с maven или ant, где скрипт это xml). Чтобы понять, что там происходит, нужно выполнить. Нужно иметь gradle внутри, и нужно чтобы gradle отдавал в IDE необходимую информацию.
Как я вижу себе декларативность, и зачем она бывает нужна? В качестве иллюстрации приведу два своих проекта, и один от apache:
Какие выводы можно из этого сделать?
Во-первых, мы видим, что с описанием проекта (в моем случае это всегда был pom.xml) иногда бывает нужно и можно работать из любого достаточно развитого языка. Это не обязан быть инструмент сборки, на который изначально расчитан проект.
Во-вторых, если репозиторий спроектирован правильно, в соответствии с принципами REST, то нам не нужен никакой специальный софт для работы с ним, кроме http-сервера. Нужны только данные метауровня чуть выше проекта (список доступных версий, например).
В-третьих, очень удобно то, что важная часть инфраструктуры, в нашем случае plugins, сами просто обычные артефакты, лежат в том же репозитории, и никак не связаны вообще с конкретным проектом.
Вот это я называю декларативным подходом. У нас есть проекты, их много. Они бывают в репозитории, в виде собранных артефактов, в VCS, и еще где-либо, и могут обрабатываться разными инструментами — а не только одним единственным. Дескриптор проекта — это просто файл, любого стандартного и удобного для обработки формата. Репозиторий артефактов — это тоже стандартизованный формат + простой REST API. А логика сборки, на любом удобном вам DSL, лежит отдельно. Хотите — в самом дескрипторе, хотите — в репозитории.
Как бы я вообще это все сделал? В сущности, если брать за основу maven, то сейчас тут не хватает гибкости в части plugins, их настроек, и т.п., потому что существующий xml — это сериализованное представление java-модели данных plugins и ядра, и оно не гибко. Если разработчики решили, что какие-то данные о проекте вам не нужны — у вас остается только вариант key-value в виде properties.
А следовало бы сделать нечто произвольной, но регулярной структуры, ну скажем типа RDF (не обязательно именно его).
Описание проекта в виде RDF сразу позволяет делать полезные вещи вроде поиска в нем, как в базе данных (т.е. репозиторий, в части метаданных, становится просто SPARQL endpoint, и умеет отвечать на поисковые запросы). И такие же запросы можно строить применительно к проекту.
Вот это и был бы истинный poliglot maven. Причем это, кстати, выглядит вполне реализуемо, даже в рамках существующей инфраструктуры.
В чем разница между Maven и Gradle
главное отличие между Maven и Gradle является то, что Maven — это инструмент управления и понимания проектов программного обеспечения, который управляет сборками проектов, отчетами и документами, а G
главное отличие между Maven и Gradle является то, что Maven — это инструмент управления и понимания проектов программного обеспечения, который управляет сборками проектов, отчетами и документами, а Gradle — это инструмент автоматизации сборки с открытым исходным кодом, ориентированный на гибкость и производительность..
Maven — это инструмент управления программными проектами, который в основном используется для проектов на основе Java. Но он также используется для управления проектами на других языках программирования, таких как C #, Scala и Ruby. Он помогает управлять сборками, документами, отчетами, зависимостями, конфигурациями программного обеспечения, выпусками и распространениями. Большинство IDE предоставляют плагины для Maven. С другой стороны, Gradle — это инструмент автоматизации сборки с открытым исходным кодом. Это официальный инструмент для сборки Android. Более того, он легко настраивается и позволяет быстро выполнять задачи, повторно используя результаты предыдущих выполнений.
Ключевые области покрыты
2. Что такое Gradle
3. В чем разница между Maven и Gradle
— Сравнение основных различий
Основные условия
Что такое Maven
Maven — это инструмент управления проектами, который управляет сборками проектов, зависимостями, распространением, выпусками и т. Д. Здесь сборка программного обеспечения относится к процессу, с помощью которого исходный код преобразуется в автономную форму, которую можно запустить на компьютере.
Кроме того, Maven позволяет компилировать, распространять, документировать и совместно работать в команде. Кроме того, репозиторий Maven — это каталог упакованного файла JAR с файлом pom.xml. Он имеет информацию о конфигурации для создания проекта. Здесь JAR — это пакет, который объединяет несколько файлов классов Java и связанных ресурсов в один файл для распространения.
Кроме того, в репозитории есть зависимости Maven. Существует три репозитория: локальный, центральный и удаленный. Сначала Maven выполняет поиск в локальном хранилище, затем в центральном и удаленном хранилищах. Локальный репозиторий находится на компьютере.Тем не менее, центральные и удаленные репозитории находятся в Интернете. В целом, Maven облегчает разработку проектов и управление ими.
Что такое Gradle
Gradle — это система автоматизации сборки с открытым исходным кодом. Он использует понятия Apache Ant и Apache Maven. Прежде всего, он был разработан для поддержки многопроектных сборок. Где, Gradle использует направленный ациклический график, чтобы определить порядок выполнения задач. Gradle стал популярным в течение короткого периода времени. Например, Google принял Gradle в качестве инструмента сборки по умолчанию для ОС Android.
Кроме того, Gradle основан на доменно-специфическом языке (DSL). Он не использует XML. Потому что он предназначен для решения конкретной проблемы. Кроме того, он поддерживает жизненный цикл программного обеспечения от компиляции до статистического анализа и тестирования до упаковки и развертывания.
Кроме того, Gradle предоставляет множество преимуществ. Это позволяет применять общие принципы проектирования к процессу сборки. Это помогает разработчикам создавать хорошо структурированные и поддерживаемые сборки для нескольких проектов. Кроме того, он предоставляет различные методы для управления зависимостями.
Разница между Maven и Gradle
Определение
Maven — это инструмент управления и понимания программных проектов, который в основном используется в проектах на основе Java. Gradle — это система автоматизации сборки с открытым исходным кодом, основанная на концепциях Apache Ant и Apache Maven. Таким образом, в этом основная разница между Maven и Gradle.
Разработчики
Apache Software Foundation разработал Maven. Ханс Доктер, Адам Мердок, Щепан Фабер, Питер Нидервизер, Люк Дейли, Рене Грёшке, Дац ДеБоер и Стив Эпплинг — разработчики Gradle.
Использование XML является основным отличием между Maven и Gradle. Maven использует XML. Однако Gradle не использует XML, поскольку имеет собственный DSL на основе Groovy.
Сценарии сборки
Более того, скрипты Gradle короче и чище, чем скрипты Maven.
Письменный язык
Maven написан на Java. В отличие от Gradle написана на Java, Gradle и Kotlin. Это еще одно различие между Maven и Gradle.
использование
Кроме того, основное различие между Maven и Gradle заключается в соответствующем использовании. Maven упрощает процесс сборки, предоставляет рекомендации по передовым методам разработки и обеспечивает прозрачный переход к новым функциям. С другой стороны, Gradle позволяет структурировать сборку. Кроме того, он поддерживает многопроектные сборки, повышает производительность, предоставляет простой способ миграции и различные методы управления сборками.
Заключение
Короче говоря, основное различие между Maven и Gradle заключается в том, что Maven — это инструмент управления и понимания программных проектов, который управляет сборками проектов, отчетами и документами, а Gradle — это инструмент автоматизации сборки с открытым исходным кодом, ориентированный на гибкость и производительность.
Ссылка:
1. «Maven — Введение», Apache Maven Project,
Инструменты сборки Java: Ant против Maven против Gradle
В экосистеме JVM доминируют три инструмента сборки:
Муравей с плющом
Ant был первым среди «современных» инструментов сборки. Во многих отношениях он похож на Make. Он был выпущен в 2000 году и за короткий промежуток времени стал самым популярным инструментом сборки для Java-проектов. Он имеет очень низкую кривую обучения, что позволяет любому начать использовать его без какой-либо специальной подготовки. Он основан на идее процедурного программирования.
После первоначального выпуска он был улучшен возможностью принимать плагины.
Основным недостатком был XML как формат для написания скриптов сборки. XML, будучи по своей природе иерархическим, не очень подходит для процедурного подхода к программированию, который использует Ant. Другая проблема с Ant состоит в том, что его XML имеет тенденцию становиться неуправляемо большим при использовании со всеми проектами, кроме очень маленьких.
Основным преимуществом Ant является его контроль над процессом сборки.
специалист
Maven был выпущен в 2004 году. Его целью было улучшить некоторые проблемы, с которыми сталкиваются разработчики при использовании Ant.
Maven продолжает использовать XML в качестве формата для написания спецификации сборки. Однако структура диаметрально отличается. В то время как Ant требует от разработчиков написания всех команд, которые приводят к успешному выполнению какой-либо задачи, Maven опирается на соглашения и предоставляет доступные цели (цели), которые могут быть вызваны. В качестве дополнительного, и, вероятно, наиболее важного дополнения, Maven представил возможность загрузки зависимостей по сети (позже принятую Ant через Ivy). Это само по себе революционизировало способ поставки программного обеспечения.
Однако у Maven есть свои проблемы. Управление зависимостями плохо обрабатывает конфликты между разными версиями одной и той же библиотеки (в этом Айви гораздо лучше). XML как формат конфигурации сборки строго структурирован и стандартизирован. Настройка целей (целей) сложно. Поскольку Maven сфокусирован в основном на управлении зависимостями, сложные, настраиваемые сценарии сборки на самом деле труднее писать в Maven, чем в Ant.
Конфигурация Maven, написанная на непрерывном XML, является большой и громоздкой. В больших проектах он может содержать сотни строк кода, не делая ничего «экстраординарного».
Основным преимуществом Maven является его жизненный цикл. Пока проект основан на определенных стандартах, с Maven можно относительно легко пройти весь жизненный цикл. Это происходит за счет гибкости.
В то же время интерес к DSL (предметно-ориентированным языкам) продолжал расти. Идея состоит в том, чтобы иметь языки, предназначенные для решения проблем, относящихся к определенной области. В случае сборок одним из результатов применения DSL является Gradle.
Gradle
Gradle сочетает в себе хорошие части обоих инструментов и строит поверх них DSL и другие улучшения. Он обладает мощью и гибкостью Ant, а также жизненным циклом Maven и простотой использования. Конечным результатом является инструмент, который был выпущен в 2012 году и привлек много внимания за короткий период времени. Например, Google принял Gradle в качестве инструмента сборки по умолчанию для ОС Android.
Gradle не использует XML. Вместо этого у него был собственный DSL на основе Groovy (один из языков JVM). В результате скрипты сборки Gradle имеют тенденцию быть намного короче и понятнее, чем написанные для Ant или Maven. Объем стандартного кода намного меньше с Gradle, поскольку его DSL предназначен для решения конкретной проблемы: продвижение программного обеспечения через его жизненный цикл, от компиляции до статического анализа и тестирования до упаковки и развертывания.
Он использует Apache Ivy для JAR-зависимостей.
Усилие Gradle может быть суммировано как «условность хороша, как и гибкость».
Примеры кода
Мы создадим сценарии сборки, которые будут компилироваться, выполнять статический анализ, запускать модульные тесты и, наконец, создавать файлы JAR. Мы выполним эти операции во всех трех средах (Ant, Maven и Gradle) и сравним синтаксис. Сравнивая код для каждой задачи, мы сможем лучше понять различия и принять обоснованное решение относительно выбора инструмента для сборки.
Maven vs Gradle? Это неправильная постановка вопроса
Написать, наконец, этот пост меня заставила уже давняя дискуссия вот к этому посту на тему, которая время от времени всплывает то там, то тут.
Я много раз имел возможность убедиться, что далеко не все одинаково понимают, в чем же состоит декларативность vs процедурность той или иной системы сборки. Основным достоинством инструмента сборки зачастую считается возможность писать алгоритмы сборки на удобном языке. Нужен DSL, никуда без него.
В gradle этот DSL базируется на groovy. sbt использует скалу, leiningen — Clojure, Ant использует xml (совершенно не по делу, кстати). Несложно припомнить системы сборки на базе javascript. Каждый собирает на том языке, который ему ближе. И новые инструменты пишут, например, на котлине.
Увы, но наличие DSL совсем не означает декларативности. Скорее наоборот. В итоге, gradle проект вообще не может полноценно жить без pom.xml. Это шутка, но с большой долей правды. Посмотрите вот сюда: это репозиторий.
Что у нас тут лежит? Да-да, именно pom.xml, он самый. А где же у нас build.gradle? А нет его. Понимаете? Его тут нет.
То есть все метаданные, которые предоставлены о собранном проекте, который заметим, собирается при помощи gradle, состоят только и исключительно из метаданных maven.
Вас это не удивляет? Меня — нисколько. На мой взгляд, gradle, sbt, leiningen и многие другие инструменты почти (или вовсе) не предоставляют метаданных в доступном другим продуктам виде.
Они реально видны только самим себе, и только изнутри процесса сборки. Просто потому, что скрипт сборки — это груви код (Clojure, скала, javascript). Именно поэтому же их так плохо поддерживают IDE (в сравнении с maven или ant, где скрипт это xml). Чтобы понять, что там происходит, нужно выполнить. Нужно иметь gradle внутри, и нужно чтобы gradle отдавал в IDE необходимую информацию.
Как я вижу себе декларативность, и зачем она бывает нужна? В качестве иллюстрации приведу два своих проекта, и один от apache:
Во-первых, мы видим, что с описанием проекта (в моем случае это всегда был pom.xml) иногда бывает нужно и можно работать из любого достаточно развитого языка. Это не обязан быть инструмент сборки, на который изначально расчитан проект.
Во-вторых, если репозиторий спроектирован правильно, в соответствии с принципами REST, то нам не нужен никакой специальный софт для работы с ним, кроме http-сервера. Нужны только данные метауровня чуть выше проекта (список доступных версий, например).
В-третьих, очень удобно то, что важная часть инфраструктуры, в нашем случае plugins, сами просто обычные артефакты, лежат в том же репозитории, и никак не связаны вообще с конкретным проектом.
Вот это я называю декларативным подходом. У нас есть проекты, их много. Они бывают в репозитории, в виде собранных артефактов, в VCS, и еще где-либо, и могут обрабатываться разными инструментами — а не только одним единственным. Дескриптор проекта — это просто файл, любого стандартного и удобного для обработки формата. Репозиторий артефактов — это тоже стандартизованный формат + простой REST API. А логика сборки, на любом удобном вам DSL, лежит отдельно. Хотите — в самом дескрипторе, хотите — в репозитории.
Как бы я вообще это все сделал? В сущности, если брать за основу maven, то сейчас тут не хватает гибкости в части plugins, их настроек, и т.п., потому что существующий xml — это сериализованное представление java-модели данных plugins и ядра, и оно не гибко. Если разработчики решили, что какие-то данные о проекте вам не нужны — у вас остается только вариант key-value в виде properties.
А следовало бы сделать нечто произвольной, но регулярной структуры, ну скажем типа RDF (не обязательно именно его).
Описание проекта в виде RDF сразу позволяет делать полезные вещи вроде поиска в нем, как в базе данных (т.е. репозиторий, в части метаданных, становится просто SPARQL endpoint, и умеет отвечать на поисковые запросы). И такие же запросы можно строить применительно к проекту.
Вот это и был бы истинный poliglot maven. Причем это, кстати, выглядит вполне реализуемо, даже в рамках существующей инфраструктуры.
Кто круче: Maven или Gradle?
Таким вопросом часто задаются начинающие разработчики, выбирая лучший сборщик для своего Java-проекта. Давайте попробуем немного разобраться в этом совсем неоднозначном вопросе.
Кто проще?
Скрипты сборки Gradle, написанные на Groovy, на порядок короче XML, используемых Maven. Разница заметна уже на hello world.
Hello world на Maven:
Hello world на Gradle:
Обратите внимание, что зависимость в Gradle записывается одной (!) строкой, вместо 4-6 в Maven. Но за простотой скриптов скрываются сложная модель сборки, особенности Groovy и DSL Gradle. Удивительно, но в этом build.gradle записаны не массивы и задание параметров, а полноценные вызовы методов (!). А аналог scope в Gradle называется конфигурацией, и их может быть 13, помимо пользовательских. Проще ли это?
Кто быстрее?
Безусловно, Gradle быстрее Maven. Впечатляющие графики и GIF-ку можно посмотреть здесь. Чтобы Gradle максимально быстро собирал ваш проект, в нём используются всевозможные кэши и даже специальный процесс – Gradle Daemon, живущий после сборки. Но если вы отключите Gradle Daemon на CI (или осуществляете сборку не так часто), то прирост в скорости станет не такой очевидный.
Русские Блоги
Разница между Maven и Gradle
Предисловие
В мире Java есть три основных инструмента сборки: Ant, Maven и Gradle. После нескольких лет разработки Ant почти исчез, Maven также приходит в упадок, а разработка Gradle бурно развивается. Я имею честь быть свидетелем упадка Maven и подъема Gradle. Основные функции Maven в основном разделены на 5 пунктов: система управления зависимостями, многомодульное построение, согласованная структура проекта, согласованная модель построения и механизм подключаемых модулей. Maven и Gradle имеют свои достоинства в использовании и используют их в соответствии со сценарием использования.
1. Сравнение Maven и Gradle
Maven необходимо ввести зависимость pom.xml
И Gradle представляет build.gradle
Преимущества: Gradle эквивалентен комбинации Maven и Ant.
Недостатки: для ссылок на подклассы микросервисов и мультипроектов он не так хорош, как Maven.
Структура / зависимости проекта определяются файлом pom.xml
Производственный код хранится в src / main / java.
Тестовый код хранится в src / test / java.
Структура / зависимости проекта определяются build.gradle
Производственный код хранится в src / main / java.
Тестовый код хранится в src / test / java.
2. Процесс сборки и жизненный цикл
3. Управление пакетами и транзитивные зависимости
Используйте компонентную систему Ivy, которая является расширенным набором компонентной системы Maven.
Совместим с репозиториями Maven
Когда есть конфликт зависимостей
Конфликт зависимостей Mavenc.png
В крупномасштабных проектах постепенно будут возникать проблемы с производительностью.
Поскольку разработка Maven в основном зависит от поддержки сообщества, больше нет средств для продолжения разработки и поддержки Maven, что приводит к остановке разработки.
Внутри Gradle есть механизм кеширования (когда ввод и вывод файла не изменились, считается, что это неизменный код, а вывод выполняется напрямую. Но когда вы меняете зависимую версию пакета, она иногда не обновляется, что также является проблемой с механизмом кеширования), который будет работать быстрее.
Активная разработка, слишком много версий
Если это полезно для вас, следите за блогом и официальным аккаунтом. Время от времени делитесь новейшими передовыми технологиями и общими технологиями производителей летучих мышей и добавляйте группы, чтобы время от времени делиться живыми лекциями и материалами видеокурсов о крупных коровах в отрасли.
Интеллектуальная рекомендация
Краткое описание общих функций MPI
содержание 1, основная функция MPI 2, точка-точка функция связи 3, коллективная функция связи 1, основная функция MPI MPI_Init(&argc, &argv) Информировать системы MPI для выполнения всех необх.
Примечание 9: EL выражение
JVM память
концепция Виртуальная машина JVM управляет собственной памятью, которая разделяет память во многие блоки, наиболее распространенной для памяти стека и памяти кучи. 1 структура виртуальной машины JVM H.
Проблема сетевого запроса на Android 9.0
вЗапустите Android 9 (API Уровень 28) или вышеНа устройстве операционной системы Android, чтобы обеспечить безопасность пользовательских данных и устройств, использование по умолчанию для зашифрованно.
Учебная запись по Webpack (3) В статье рассказывается о создании webpack4.0.
предисловие Для изучения веб-пакета автор также предпринял много обходных путей. Есть много вещей, которые я хочу знать, но я не могу их найти. Автор поможет вам быстро начать работу. Цель этой статьи.
