Да, вот только, из вашего примера не было ясно, что в дочерних помах нету ссылок на родителя — только структура каталогов — а она как раз самая, что ни на есть классическая :) Что касается наследования и агрегирования, то мне ближе наследование между иерархией (деревом) супер помов и проектами (пример 1), тогда как внутри проектов я предпочитаю комбинацию агрегирования и наследования, как в 5 примере.
Да, конечно, проект может иметь несколько уровней вложенности, например, https://bitbucket.org/JRS/open-flexess/src. Но я и в этом случае придерживаюсь правила — создавать каталог для узловых "pom" файлов по причинам, изложенным выше в статье. Но у вашего варианта есть одно большое преимущество — он стандартный :)
Спасибо за статью. Есть у меня одно замечание по поводу зависимости com.google.dagger:dagger-compiler:2.0. Для Dagger‡ и других APT-based продуктов лучше пользоваться gradle-apt-plugin. Это сделает компиляцию вашего проекта более прозрачной и безопасной, так как не будут путаться два разных classpath'а — один для компиляции вашего кода и второй для его генерации.
Немного устаревшие данные. Последний релиз поддерживает и Java 9, правда только как компилятор. Языковые конструкции обещают в следующем релизе. Т.е. сейчас можно писать на Java 8 и это скомпилируется Java SDK 9. Но статься не об этом :)
Да, репозитории в помах это еще та чехарда — при большом количестве проектов и длинной истории могут создавать вполне реальные проблемы. Я для себя со временем пришел к такому решению — на рабочий комп ставится sonatype nexus (maven repository), a settings.xml содержит единственную запись:
Сначала о недостатках — репозиторий отбирает часть ресурсов у компа, особенно место на диске. Но это достаточно просто нивелируется железом. Достаточно сказать, что я полгода не замечал фоновый WebSphere Full Profile + Liferay + Application (забыл выключить после смены проекта), чтобы понять, что этот недостаток не так существеннен.
Теперь о достоинствах:
весь роутинг — мои репозитории + OSS репозитории + проектовые репозитории управляются через nexus (Web UI), что гораздо удобнее чем руками в XML
мне не надо теперь иметь несколько settings.xml (для работы и для себя). Nexus автоматически отслеживает доступность репозиториев и автоматически их подключает.
оптимизация трафика — Nexus "умнее" общается с удалёнными репозиториями
локальный репозиторий (не nexus) со временем забивается мусором, но в моём случае это не важно — я легко могу его стереть — всё нужное моментально восстановится из nexus
Мне помог Mommox. В принципе, любой спрей с мометазона фуроатем. Правда, у нас он только по рецепту. Действует не сразу, но после 3-4 недель я забыл о нафтизине (до этого заснуть без него не мог). Главное поверить врачу и пережить первые 2-3 недели.
1. Я возможно вас обижу, наверное, но сложная иерархия в многомодульных проектах часто возникает из-за ошибок проектирования, а с простой иерархией maven справляется на раз.
2. Ничего не могу сказать — вполне возможно, что это и так. Я документацию не генерирую, а когда приходилось по работе (проект из 10-20 модулей) никогда проблем не было. Правда мы её настраивать не пытались :) Результат «из коробки» нас вполне устроил.
3. Не очень понял :) Куда положить? У меня проекты через 2-3 транзитивные зависимости вполне внятно работают с исходниками (для GWT надо) Где организовать? IDE сама разбирается, CI сервер тоже (хотя я это сейчас не использую)
4. Можно, но сложно (очень сложно) — и это плюс IMHO
5. А вот тут я с вами соглашусь, пожалуй. Maven это только для Java.
Да, есть такая буква. Properry нельзя импортировать. Как и настройки билда, плагинов. А версии то почему нет? С правильного BOM'а подтянутся все версии сами. Надо лишь указать правильную версию самого BOM'а.
Ну вот нет у меня этих аргументов. Не сердитесь :) Просто maven это инструмент, который меня пока сильно не подводил. Что бы понять билд чужого проекта надо просто знать мавен, а не заниматься reverse engineering. Я не говорю, о том, как вносить исправления — ведь для этого придётся не просто понять, что делает данный скрипт, но и зачем он это делает, и какая идея за этим стоит.
В то время как у maven модель фиксированная, что значительно облегчает работу с проектами. Опять же юниор на проекте не успееет много сломать. Можно вовремя его поправить.
Честно говоря — нет у меня такого опыта, первое, что я сделал, когда смотрел на spring boot, это можно ли его использовать без их parent POM. Оказалось, что да, и дальше я не копал :)
А… Ну хорошо, что он её нашел. Я же писал, в основном, для тех, кто продолжает «мучиться» с maven по разным причинам. Кому-то он достался в наследство, кто-то сделал осознанный выбор и использует maven или Gradle не потому, что кому-то «должен», а просто потому, что своя голова на плечах есть.
Так, а я о чём? :) Gradle отличный продукт, и не от балды его придумали, а пытаясь решить реальные проблемы. Скорее всего вызванные попыткой «сделать нестандартное». Вот только, для меня сам факт таких проблем, это звоночек, что я делаю, что-то не совсем так и повод решить возникшую проблему немного иначе. A нестандартных подходов я видел много, ещё когда с ANT работал. И всё хорошо, когда сам пишешь этот скрипт, но вот когда его пишет кто-то другой, а тебе надо кусочек поправить. Кто сталкивался, тот поймёт.
Хорошая идея, но есть несколько причин, почему я им пока не пользуюсь. Это поддержка, точнее её отсутствие, в Eclipse. Плюс, как-то у меня не получилось сходу подобрать правильный диалект, который бы мне понравился. Ну и для статьи, по любому, лучше использовать native language, то есть XML.
На вкус и цвет все фломастеры разные :) Вот тут мой ответ на твит от @CedricChampeau. Кратко — Maven мне нравится своей стройной моделью проекта. Я считаю, что рамки, которая она накладывает, это плюс, а не минус.
Ну вот, вы всё запутали :) Aутентификация — проверка того, что идетифицированный субъект, есть тот за кого себя выдает. До прав еще не дошли. Контроль доступа (access approval, access control или enforcement) проверка при действии субъекта на наличие у него прав на это действие, то что часто и, не совсем правильно, называют авторизацией по-русски.
“I have less friends than you” волне корректно если говорящий подрузамевает не количество вешей, а их, скажем так, совокупный объём. Поясню на примере:
I have a little amount of friends. -> I have less amount of friends than you. -> I have less friends than you.
Никак. Ключевая фраза "в установленных геозонах и/или дорожных условиях автомобиль двигается совершенно автономно". Как я понимаю, на не "сертифицированной" дороге это обычный автомобиль.
Да, вот только, из вашего примера не было ясно, что в дочерних помах нету ссылок на родителя — только структура каталогов — а она как раз самая, что ни на есть классическая :) Что касается наследования и агрегирования, то мне ближе наследование между иерархией (деревом) супер помов и проектами (пример 1), тогда как внутри проектов я предпочитаю комбинацию агрегирования и наследования, как в 5 примере.
Да, конечно, проект может иметь несколько уровней вложенности, например, https://bitbucket.org/JRS/open-flexess/src. Но я и в этом случае придерживаюсь правила — создавать каталог для узловых "pom" файлов по причинам, изложенным выше в статье. Но у вашего варианта есть одно большое преимущество — он стандартный :)
Спасибо за статью. Есть у меня одно замечание по поводу зависимости
com.google.dagger:dagger-compiler:2.0
. Для Dagger‡ и других APT-based продуктов лучше пользоваться gradle-apt-plugin. Это сделает компиляцию вашего проекта более прозрачной и безопасной, так как не будут путаться два разных classpath'а — один для компиляции вашего кода и второй для его генерации.Сейчас всё намного приятнее:
Например JavaScript
Тот же код из Java (JS Interop)
Тот же код из Java (JS Interop + Custom builder on Java)
Да, репозитории в помах это еще та чехарда — при большом количестве проектов и длинной истории могут создавать вполне реальные проблемы. Я для себя со временем пришел к такому решению — на рабочий комп ставится sonatype nexus (maven repository), a settings.xml содержит единственную запись:
Сначала о недостатках — репозиторий отбирает часть ресурсов у компа, особенно место на диске. Но это достаточно просто нивелируется железом. Достаточно сказать, что я полгода не замечал фоновый WebSphere Full Profile + Liferay + Application (забыл выключить после смены проекта), чтобы понять, что этот недостаток не так существеннен.
Теперь о достоинствах:
Мне помог Mommox. В принципе, любой спрей с мометазона фуроатем. Правда, у нас он только по рецепту. Действует не сразу, но после 3-4 недель я забыл о нафтизине (до этого заснуть без него не мог). Главное поверить врачу и пережить первые 2-3 недели.
2. Ничего не могу сказать — вполне возможно, что это и так. Я документацию не генерирую, а когда приходилось по работе (проект из 10-20 модулей) никогда проблем не было. Правда мы её настраивать не пытались :) Результат «из коробки» нас вполне устроил.
3. Не очень понял :) Куда положить? У меня проекты через 2-3 транзитивные зависимости вполне внятно работают с исходниками (для GWT надо) Где организовать? IDE сама разбирается, CI сервер тоже (хотя я это сейчас не использую)
4. Можно, но сложно (очень сложно) — и это плюс IMHO
5. А вот тут я с вами соглашусь, пожалуй. Maven это только для Java.
В то время как у maven модель фиксированная, что значительно облегчает работу с проектами. Опять же юниор на проекте не успееет много сломать. Можно вовремя его поправить.
I have a little amount of friends. -> I have less amount of friends than you. -> I have less friends than you.
Скорее это будет работать, как лишний стимул воспользоваться платной дорогой — IMHO, их владельцы будут в числе первых, кто пройдёт эту "сертификацю".
Никак. Ключевая фраза "в установленных геозонах и/или дорожных условиях автомобиль двигается совершенно автономно". Как я понимаю, на не "сертифицированной" дороге это обычный автомобиль.