Компания в которой я работаю, действительно против вклада в opensource и вообще всей активности во внешнем мире со стороны сотрудников.
Мне, например, предъявили серьезные претензии за статью, опубликованную на Хабре, потому как во-первых я должен был согласовать ее с безопасниками, стоит также отметить, что никакой конфиденциальной информации в статье не было, и даже отделом маркетинга, а во-вторых публиковать не от своего аккаунта, а именно от корпоративного, лишь с отсылкой на авторство. Естественно, я воспротивился этому и даже отстоял свою позицию, ввиду слабой юридической поддержки их требований, однако, спустя где-то пару месяцев вышло внутреннее распоряжение, покрывающее данные уязвимости юр. части.
Вот и приходится править инструменты, с которыми работаешь, во внеурочное время и коммитить из-под другого аккаунта, хотя даже это можно юридически подтянуть в соответствии с вышеуказанным распоряжением.
Ситуации действительно бывают разные. Я понимаю и принимаю позицию тех, кто тратит свободное время на семью, поскольку это гораздо важнее чем работа, opensource community, даже чем будущее всей индустрии вцелом. У меня есть такие сотрудники и я понимаю их.
Сам я, чтобы не тратить время семьи либо контрибьючу рано утром, пока все спят, но не все просыпаются в шесть утра, либо поздно ночью, когда все уже спят, либо когда я один дома и не надо на работу.
Опа…
Пойду перечитывать документацию — у меня подмена понятий произошла, поскольку я тоже использую комбинирование, только в качестве парента корневой от агрегации и суперпом на нем как парент, а не bom.
На самом деле описанный мной способ и указанный в статье, оба являются стандартами — aggregation и inheritance, со своими особенностями. Просто лично я предпочитаю аггрегацию=)
Есть один момент, с которым я лично столкнулся с перекупами. Была авария, достаточно серъезная на моем авто, я всадил 2114, который не предоставил права преимущественного проезда на зеленый сигнал светофора, прямо в бочину. На пассажирском сиденье была пассажирка, которой я вызвал скорую. В связи с пострадавшими, разбирательство шло достаточно долго, 7 месяцев, если быть точным. Получив спустя эти 7 месяцев справку, я запостил автомобиль на продажу с повреждениями — там и лонжерон под замену, и крылья, и капот и далее по списку. Смотрел по базам, повреждений не было указано вообще, хотя автомобиль, ясное дело, передвигался с трудом. Спустя дня 3, может 4 у меня ее купили перекупы, а еще через неделю уже продали и лишь спустя где-то месяц повреждения отобразились в базах.
Так что, если перекупы сделают все быстро, то новый владелец может узнать, как в моем случае, спустя некоторое время после покупки. Вот такие пироги.
Относительно корневого пома, лишь отчасти согласен, все дело в том, что он передает абсолютно все параметры настройки как плагинов, так и зависимостей, в частности чтобы избежать jar-hell, а также для конфигурации всего проекта из единого файла, и такая конфигурация в Gradle содержала бы не намного меньше параметров и строчек кода и только благодаря прямому указанию параметров в одной строке, например зависимостей, но не более того — я знаю это потому что писал многомодульные проекты как на одном так и на другом.
Обратите внимание лучше на подмодули проекта, например github.com/vporoxnenko/mbsa/blob/master/server/document/pom.xml и его подмодуль github.com/vporoxnenko/mbsa/blob/master/server/document/ui/pom.xml — они достаточно компактны именно благодаря большому корневому pom'у и наследованию параметров от вышестоящих объектов, в компаниях же данную проблему решает superpom, который не было смысла выделять в данном проекте.
Для примера, superpom в моей компании содержит 800 строк, тогда как наследуемые проекты и парент-помы подпроектов компании, благодаря ему не более 300.
Добавлю свои 5 копеек:
1 — практических проблем с многомодульными проектами в Maven нет, могут быть исключительно архитектурные проблемы, но с ними без костыляния и Gradle не справится.
2 — Нет никаких проблем с настройкой документации — тут вам и doxygen для специфичных видов документации, и velocity, и docbook, а оборачивается это все через пару плагинов — javadoc, site-plugin, дальше лишь решаете в каком виде вы получить это хотите.
3 — Весьма сомнительная ситуация, когда вы вместо скомпилированной зависимости проекта хотите использовать ее сборку в процессе билда — если она используется только в текущем проекте, внедрите ее как модуль, если же она используется и в других проектах, наиболее логично будет предоставить ей свой релизный цикл и устанавливать взаимоотношения через бинарные зависимости.
4 — ИМХО lifecycle Maven содержит все возможные стадии жизни исходного кода и отхождение от него также указывает на какую-то архитектурную, либо логическую ошибку в процессе сборки, другой момент, когда вы хотите вместить какую-нибудь специфичную для проекта операцию на той или иной стадии цикла, то вы просто используете фазы сборки. Мне сложно представить ситуацию когда генерация кода должна идти после компиляции, но и это не проблема, перекиньте исполнение плагина на соответствуюшую фазу и вуаля. Кроме того, если уж вам действительно необходимо это сделать, напишите свой плагин и сделайте extend на ту или иную фазу цикла, вот вам и кастомное поведение.
5 — Прекрасно все настраивается, лично писал сборку для SDK под одну платформу, где и C/C++, C#, Android с NDK, lua, Flex и т.д.
На одной из конференций был адвокат Gradle, который 1 час потратил на то, чтобы рассказать какие есть у Gradle рюшечки относительно Maven, но реальных технических оснований для перехода так и не озвучил — вот здесь есть такой красивый отчетик, вот тут оно в демоне собирается(но иногда демон подвисает и его надо жестко убивать). Все то, что он в итоге рассказал в сравнении с Maven реально просто делается и на Maven, на мой прямой вопрос почему он это сделал только с Gradle, ответом было, что он не знал что это можно сделать в Maven.
Как-то я приводил уже на хабре ссылку на проект собираемый Maven с количеством модулей 100+, с документацией, к сожалению, на чистой Java, но приведу еще один раз, на всякий случай — github.com/vporoxnenko/mbsa
P.S. Вы не любите кошек? — Да вы просто не умеете их готовить.
P.P.S. Единственное достоинство Gradle, которое я действительно оценил, это инкрементальная компиляция, которая работала стабильнее чем реализация от takari-lifecycle-plugin пару лет назад.
Но нужно понимать, что даже у них есть отделы (или отдельные люди), которые пишут на том, что стильно-модно-молодежно.
Конкретно где работал я(это кстати был отдельный «Департамент не скажу чего», т.е. полноценная муниципальная единица) — не было таких отделов, был один отдел разработчиков, которые тыкали палками свои велосипеды, чтобы они работали.
Честно говоря, не было бы претензий если бы их творение хотя бы работало, чтобы оценить всю боль испытаннную мною, приведу пример:
Есть сотни тысяч клиентов, которые должны оплачивать услуги точно в срок, в случае если оплата просрочена, необходимо начислить пени. Задача в общем-то примитивна. Храним id агента, срок оплаты, дата фактической оплаты, сумма оплаты. Исходя из этих данных берем разницу по датам оплаты и рассчитываем проценты за просрочку, но зачем такие легкие пути? — Создаем на каждый год табличку в сотни тысяч строк на каждого контрагента, затем 365(366) столбцов, оплата обновляет табличку в требуемом столбце в зависимости от дня года и вуаля — расчет задолженностей по контрагентам 18 часов.
Стоимость подобной информации возрастает, потому как никому не хочется ждать каждый раз эти 18 часов, а программисты повышают ЧСВ, ведь если оно будет написано «неправильно» людям придется ждать лишние 18 часов, а они не могут это допустить.
В общем, в госсекторе, как по моему мнению, основная проблема в некомпетентах работающих в них, что связано с достаточно низкой з/п в первых. Может быть ситуация изменилась, таки 5 лет прошло с тех пор, и мои данные устарели, но рассказываю то, что встретил в своей карьере.
З.Ы. Никого обидеть не хотел, если таки получилось — мои извинения.
Не помешало бы описать монтирование разделов, tcp_wrappers, audit, AIDE, файловым системам, да и в целом пробежаться по CIS рекомендациям — https://www.cisecurity.org/cis-benchmarks/, для тех кто пользуется ansible, есть плейбуки https://github.com/MindPointGroup/RHEL7-CIS — сам не проверял, но выглядит многообещающе.
Может быть я ретроград в этом плане, но, честно говоря, не особо люблю эту обертку, потому, как правило, удаляю и настраиваю с нуля чистый iptables.
Хороший мануал нашел в 2000 бородатом году, актуален и по сей день http://www.opennet.ru/docs/RUS/iptables/
Если плагины запускаются в одной фазе, то они исполняются в порядке описания в pom.xml, если смотреть на твой пример, у тебя там сборка jar в принципе не задана, потому как она используется по дефолту, однако, в этом случае порядок исполнения плагинов стоит проверить через генерацию эффективного пома.
Также можно перенести сбоку на фазу install. Может кто знает, как заставить Maven исполнять плагины в нужном порядке?
Мавен не руководствуется порядком написания, у него есть lifecycle в котором определены фазы сборки, для плагинов дефолтные задаются через аннотации, например:
io.fabric8.maven.docker.PushMojo
....
@Mojo(name = "push", defaultPhase = LifecyclePhase.DEPLOY)
@Execute(phase = LifecyclePhase.INITIALIZE)
public class PushMojo extends AbstractDockerMojo {
...
подробнее описано на https://maven.apache.org/developers/mojo-api-specification.html
Так что здесь необходимо посмотреть на какие фазы прибит гоал плагина, ну и переопределить при необходимости разбросав на разные фазы.
К тому же пуш контейнера в регистри вполне себе вписывается в фазу деплой, как мне кажется.
здесь достаточно большой проект, если отключить сборку документации, то занимает 3 минуты, притом на достаточно слабой виртуалке, все дело лишь в правильном приложении мавена github.com/vporoxnenko/mbsa
Мне, например, предъявили серьезные претензии за статью, опубликованную на Хабре, потому как во-первых я должен был согласовать ее с безопасниками, стоит также отметить, что никакой конфиденциальной информации в статье не было, и даже отделом маркетинга, а во-вторых публиковать не от своего аккаунта, а именно от корпоративного, лишь с отсылкой на авторство. Естественно, я воспротивился этому и даже отстоял свою позицию, ввиду слабой юридической поддержки их требований, однако, спустя где-то пару месяцев вышло внутреннее распоряжение, покрывающее данные уязвимости юр. части.
Вот и приходится править инструменты, с которыми работаешь, во внеурочное время и коммитить из-под другого аккаунта, хотя даже это можно юридически подтянуть в соответствии с вышеуказанным распоряжением.
Ситуации действительно бывают разные. Я понимаю и принимаю позицию тех, кто тратит свободное время на семью, поскольку это гораздо важнее чем работа, opensource community, даже чем будущее всей индустрии вцелом. У меня есть такие сотрудники и я понимаю их.
Сам я, чтобы не тратить время семьи либо контрибьючу рано утром, пока все спят, но не все просыпаются в шесть утра, либо поздно ночью, когда все уже спят, либо когда я один дома и не надо на работу.
Пойду перечитывать документацию — у меня подмена понятий произошла, поскольку я тоже использую комбинирование, только в качестве парента корневой от агрегации и суперпом на нем как парент, а не bom.
На самом деле описанный мной способ и указанный в статье, оба являются стандартами — aggregation и inheritance, со своими особенностями. Просто лично я предпочитаю аггрегацию=)
Дело конечно каждого, лично я больше за вложенную структуру проекта, визуально более понятно, прозрачное наследование, зависимости:
Так что, если перекупы сделают все быстро, то новый владелец может узнать, как в моем случае, спустя некоторое время после покупки. Вот такие пироги.
Относительно корневого пома, лишь отчасти согласен, все дело в том, что он передает абсолютно все параметры настройки как плагинов, так и зависимостей, в частности чтобы избежать jar-hell, а также для конфигурации всего проекта из единого файла, и такая конфигурация в Gradle содержала бы не намного меньше параметров и строчек кода и только благодаря прямому указанию параметров в одной строке, например зависимостей, но не более того — я знаю это потому что писал многомодульные проекты как на одном так и на другом.
Обратите внимание лучше на подмодули проекта, например github.com/vporoxnenko/mbsa/blob/master/server/document/pom.xml и его подмодуль github.com/vporoxnenko/mbsa/blob/master/server/document/ui/pom.xml — они достаточно компактны именно благодаря большому корневому pom'у и наследованию параметров от вышестоящих объектов, в компаниях же данную проблему решает superpom, который не было смысла выделять в данном проекте.
Для примера, superpom в моей компании содержит 800 строк, тогда как наследуемые проекты и парент-помы подпроектов компании, благодаря ему не более 300.
1 — практических проблем с многомодульными проектами в Maven нет, могут быть исключительно архитектурные проблемы, но с ними без костыляния и Gradle не справится.
2 — Нет никаких проблем с настройкой документации — тут вам и doxygen для специфичных видов документации, и velocity, и docbook, а оборачивается это все через пару плагинов — javadoc, site-plugin, дальше лишь решаете в каком виде вы получить это хотите.
3 — Весьма сомнительная ситуация, когда вы вместо скомпилированной зависимости проекта хотите использовать ее сборку в процессе билда — если она используется только в текущем проекте, внедрите ее как модуль, если же она используется и в других проектах, наиболее логично будет предоставить ей свой релизный цикл и устанавливать взаимоотношения через бинарные зависимости.
4 — ИМХО lifecycle Maven содержит все возможные стадии жизни исходного кода и отхождение от него также указывает на какую-то архитектурную, либо логическую ошибку в процессе сборки, другой момент, когда вы хотите вместить какую-нибудь специфичную для проекта операцию на той или иной стадии цикла, то вы просто используете фазы сборки. Мне сложно представить ситуацию когда генерация кода должна идти после компиляции, но и это не проблема, перекиньте исполнение плагина на соответствуюшую фазу и вуаля. Кроме того, если уж вам действительно необходимо это сделать, напишите свой плагин и сделайте extend на ту или иную фазу цикла, вот вам и кастомное поведение.
5 — Прекрасно все настраивается, лично писал сборку для SDK под одну платформу, где и C/C++, C#, Android с NDK, lua, Flex и т.д.
На одной из конференций был адвокат Gradle, который 1 час потратил на то, чтобы рассказать какие есть у Gradle рюшечки относительно Maven, но реальных технических оснований для перехода так и не озвучил — вот здесь есть такой красивый отчетик, вот тут оно в демоне собирается(но иногда демон подвисает и его надо жестко убивать). Все то, что он в итоге рассказал в сравнении с Maven реально просто делается и на Maven, на мой прямой вопрос почему он это сделал только с Gradle, ответом было, что он не знал что это можно сделать в Maven.
Как-то я приводил уже на хабре ссылку на проект собираемый Maven с количеством модулей 100+, с документацией, к сожалению, на чистой Java, но приведу еще один раз, на всякий случай — github.com/vporoxnenko/mbsa
P.S. Вы не любите кошек? — Да вы просто не умеете их готовить.
P.P.S. Единственное достоинство Gradle, которое я действительно оценил, это инкрементальная компиляция, которая работала стабильнее чем реализация от takari-lifecycle-plugin пару лет назад.
Конкретно где работал я(это кстати был отдельный «Департамент не скажу чего», т.е. полноценная муниципальная единица) — не было таких отделов, был один отдел разработчиков, которые тыкали палками свои велосипеды, чтобы они работали.
Честно говоря, не было бы претензий если бы их творение хотя бы работало, чтобы оценить всю боль испытаннную мною, приведу пример:
Есть сотни тысяч клиентов, которые должны оплачивать услуги точно в срок, в случае если оплата просрочена, необходимо начислить пени. Задача в общем-то примитивна. Храним id агента, срок оплаты, дата фактической оплаты, сумма оплаты. Исходя из этих данных берем разницу по датам оплаты и рассчитываем проценты за просрочку, но зачем такие легкие пути? — Создаем на каждый год табличку в сотни тысяч строк на каждого контрагента, затем 365(366) столбцов, оплата обновляет табличку в требуемом столбце в зависимости от дня года и вуаля — расчет задолженностей по контрагентам 18 часов.
Стоимость подобной информации возрастает, потому как никому не хочется ждать каждый раз эти 18 часов, а программисты повышают ЧСВ, ведь если оно будет написано «неправильно» людям придется ждать лишние 18 часов, а они не могут это допустить.
В общем, в госсекторе, как по моему мнению, основная проблема в некомпетентах работающих в них, что связано с достаточно низкой з/п в первых. Может быть ситуация изменилась, таки 5 лет прошло с тех пор, и мои данные устарели, но рассказываю то, что встретил в своей карьере.
З.Ы. Никого обидеть не хотел, если таки получилось — мои извинения.
В 2012 году лично познакомился с АРМами написанными на VBA под MS Access 97.
нехватает:
-l Bind and listen for incoming connectionsnc -lu localhost 7777Хороший мануал нашел в 2000 бородатом году, актуален и по сей день http://www.opennet.ru/docs/RUS/iptables/
build из докер плагина будет исполнен раньше запуска jar плагина
Мавен не руководствуется порядком написания, у него есть lifecycle в котором определены фазы сборки, для плагинов дефолтные задаются через аннотации, например:
подробнее описано на https://maven.apache.org/developers/mojo-api-specification.html
Так что здесь необходимо посмотреть на какие фазы прибит гоал плагина, ну и переопределить при необходимости разбросав на разные фазы.
К тому же пуш контейнера в регистри вполне себе вписывается в фазу деплой, как мне кажется.
github.com/vporoxnenko/mbsa