Комментарии 7
Посмотрел исходники. Получается, что параметры плагинов зашиты в сами плагины, например версия sdk, build tools и т.д. Скажем есть два вообще разных приложения с разными minSdkVersion, то как применить ваши плагины к этим приложения?
Это сделано как пример. В моем случае есть больше пяти приложений, с одинаковыми версиями, поэтому я вынес общие параметры в плагин. Если у вас всего два приложения с разными параметрами, то смысла использовать плагины конечно нет.
Можно еще как вариант немного переписать плагин и добавить возможность переопределять параметры, в примере с плагином для публикации я добавил несколько таких параметров.
Можно еще как вариант немного переписать плагин и добавить возможность переопределять параметры, в примере с плагином для публикации я добавил несколько таких параметров.
Столько антипаттернов и все из-за желания сэкономить пару модулей.
- Разнеся код по разным модулям, мы гарантируем прозрачность зависимостей между ними.
Если они действительно независимы — то это будет проверено на уровне компилятора. Если есть зависимость, то она будет явно прописана и видна в pom.xml. - Подключая только одну библиотеку, никогда нельзя быть уверенным, что зависимость на другую не потребуется.
- Библиотеки невозможно релизить независимо.
А можно поподробней про антипаттерны? Мне кажется вы сами себе противоречите в первом и втором пункте. В моих примерах предполагается что модули независимы. Если необходимо подключить какой-то свой модуль, который зависит от чего то еще это всегда можно дописать в pom.xml, придется немного поправить проект.
А по поводу пункта 3, то каждый отдельный модуль можно релизить независимо. Для каждого автоматически создается отдельная задача, я это все описал в статье.
А по поводу пункта 3, то каждый отдельный модуль можно релизить независимо. Для каждого автоматически создается отдельная задача, я это все описал в статье.
- Когда код лежит в одном модуле, то классы легко могут ссылаться друг на друга и никто это не контролирует. А когда код разнесен по модулям, компилятор проверит, что код использует классы из библиотек на которые указанан зависимость.
- Это следует из первого пункта: пусть у нас пока utils и logger независимы. И некий модуль использует только logger. Потом после маленького апдейта logger, в нем заюзали один метод из utils и все ClassNotFoundException после апдейта готов.
- Для библиотеки из 3-х классов, это не актуально конечно, но для более серькзных вещей жизненный цикл релизов будет выглядеть криво.
Вот у нас есть есть 2 библиоткеки utils:1.0 и logger:1.0. Мы нашли неприятный баг в utils, быстро зафиксали его и надо зарелизить. Плюс у нас есть один готовый чейндж в logger и один ожидающий реализации для релиза logger:1.1.
И у нас получается выбор: релизить только utils:1.1, забив на то что мы еще получаем полурелизный logger в VCS теге. Или делать предрелиз logger:1.1/2. Оба варианта не смертельны, но кривоваты с т.з. жизненного цикла.
Раз уж мы подняли эту тему, объясните что вы получили сэкономив один модуль?
По итогу я получил то что у меня разные приложения используют один и тот же функционал и мне не нужно следить в каком приложении более актуальная версия кода. И большая часть приложений содержит build.gradle в котором все настройки заменены на использование плагинов. Что так же не мало важно для меня, потому то они однотипные и вся их базовая функциональность реализована в отдельной библиотеке.
Если интересует что я выносил в компоненты, то это работа с внутренним API, работа с хардварными устройствами (принтеры, сканеры и т.д.) ну и действительно пакет util, с разными вспомогательными классами.
На сколько я понял вы предлагаете работать в одном проекте, и использовать разные модули, т.е. в таком случае предполагается модуль util и зависимость на него compile ':util'? Но это не рабочий вариант если есть много приложений (в моем случае > 10). Я даже не представляю как будет тормозить у меня студия собирая приложение.
А по поводу зависимостей самих компонентов, то никто не мешает создать pom.xml с правильным dependencies.
Если интересует что я выносил в компоненты, то это работа с внутренним API, работа с хардварными устройствами (принтеры, сканеры и т.д.) ну и действительно пакет util, с разными вспомогательными классами.
На сколько я понял вы предлагаете работать в одном проекте, и использовать разные модули, т.е. в таком случае предполагается модуль util и зависимость на него compile ':util'? Но это не рабочий вариант если есть много приложений (в моем случае > 10). Я даже не представляю как будет тормозить у меня студия собирая приложение.
А по поводу зависимостей самих компонентов, то никто не мешает создать pom.xml с правильным dependencies.
Если у вас в одном модуле лежит код одной библиотеки, то и собираться он будет одним плагином с минимумом конфигурирования.
Пассаж насчет количества приложений я вообще не понял. Вы же пишете некую общую библиотеку. Какая разница сколько приложений его используют?
Я не говорил, что нельзя, я говорю что это не проверяется автоматически и можно забыть.
Пассаж насчет количества приложений я вообще не понял. Вы же пишете некую общую библиотеку. Какая разница сколько приложений его используют?
Я не говорил, что нельзя, я говорю что это не проверяется автоматически и можно забыть.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разносим общий функционал приложений и конфигурации Gradle в отдельные модули