Да, противоречит. Опять про дверь в поле…
С xml в target, я и не говорил, что это изящное решение. Я просто сказал, что это возможно, если очень хочется. А вообще, если хочется чего-нибудь такого, нужно остановиться, оглянуться, и подумать еще раз. Скорее всего вы собрались делать что-то не правильно.
Ну почему? Если вы о переиспользовании кода, то пожалуйста, сделайте этот код отдельным артифактом и подтягивайте зависимостью в оба плагина. Если вы о прямом, кхм, использовании одного плагина в другом… но это же в корне нарушает всю идею жизненного цикла. Я вижу в этой изолированности только фичу. К тому-же, засериализовать в target директорию какой-то xml всегда можно, что бы потом оттуда прочитать, в том-же билде.
Да в использовании тренарных операций и нет ничего плохого, по сути. Но сам момент — сначала убираем скобки, вот теперь классно. Хотя нет, давайте вообще тренарный оператор заюзаем.
Как по мне, это не упростило читабельность кода, а усложнило ее. Убрало «блоки» кода, между которыми я мог фокусировать свое внимание. Меньше строк кода — не значит читабельнее.
Я думаю, Антон читает мыло, так что рано или поздно он тут появится :)
Чем же плагины ограничены? Это обычный джава код, все ограничение составляет JVM. И писать, как по мне, вовсе не сложно. Да, понимаю, на Градле легче, но в соседнем топике мы с вами это уже обсуждаем…
Под стандартом я имел ввиду конвеншны — четкий стандартный лайф цайкл, и тому подобные вещи, которые мавен нам диктует. Грейдл диктует то-же самое, но в то же время, пожалуйста, пишите код в конфигурационном файле билда. Не похоже ли это на бронированную дверь посреди поля, без стены и так далее? Хочешь — воспользуйся ключем и пройди в дверь. Нет — сделай шаг в лево и обойди ее.
Все описанные проблемы легко решаются своим кастомным кодом — плагинами. И мне кажется, гораздо безопаснее написать свой плагин и объявить его декларативно, чем начать творить магию прямо в конфигурации билда.
Но Грейдл все таки ЯП, и это возможно. А запретный плод сладок. И это так искусительно. И если мы не будем тратить 30% рабочего времени на мониторинг и модерирование билд файлов, это будет просто замечательно.
А Мавен своей декларативностью и не-ЯПобразием сразу отбивает все желание самодеяльничать. И тогда в случае необходимости, девелоперы идут к нам. И в большинстве случаев предлагаемое ими решение ущемляет интересы других команд или доменов, и вообще не по фен-шую.
Но ладно, давайте оставим эту тему, я думаю мы друг друга поняли. А как на счет порога вхождения? Мавен — стандарт, найти человека, ориентирующегося в этом стандарте — легко. Грейдл дает нам такой стандарт? Или нам нужно будет придумывать свою архитектуру процесса сборки, а потом каждого новенького кроме всего прочего еще и обучать нашей архитектуре и конвеншнам?
Я боюсь, вы не понимаете, насколько быстро растет сложность и падает скорость синхронизации узлов девелопмент-центра с увеличением размера этого центра и введения понятия распределенной разработки. Давайте тогда верстальщиков учить код править так, как им надо? Не дадите? Почему? Ааа, у вас метрики, эстимейты, архитектуру обсудить нужно?
У нас тоже есть свои архитекторы, менеджеры, бэклоги, метрики, лонг-терм гоалы и так далее. Вы думаете, впускать в этот процесс девелоперов хорошо отразиться на общих сроках выполнения задач и метриках? Думаете, девелоперы лучше знать будут, то хорошо для QA и менеджеров? Я думаю, что каждый должен заниматься своим делом. Мы не обслуживающий персонал, призванный ублажать и облегчать жизнь девелоперам, мы такие же девелоперы. И каждый должен делать свою работу.
В этом я тоже абсолютно согласен. Как я и сказал, большая половины выступления мне понравилась. Но когда, например, Антон говорил, что в if не надо писать скобки, и вообще можно обойтись тренарным оператором — меня как-то передергивало.
О его солидном опыте я знаю, мой опыт нервно курит в сторонке. Потому очень жажду дискуссии на эту тему. Хотя, с другой стороны больше половины этого опыта — преподавание в вузе и работа на банк. Я, конечно, не знаю как там у них в Таллине, но есть мнение, что такой опыт заставляет мыслить несколько узковато.
Тем не менее, отступить от стандарта легко и просто прямо в билд файле, что будет добавлять работы в Build Factory, когда какой то девелопер решит, что он лучше знает. А с мавеном не так просто — надо плагин написать, задеплоить его в соответствующий корпоративный репозиторий (на что права нужны), и так далее. Спорить более подробно я не буду, опыта с Gradle не так много. За ссылку спасибо.
Я абсолютно согласен. Это характерная черта. Даже само название Java 2 Ынтырпрайз Edition как-бы намекает.
Речь идет немного о другом. Я работал на проекте, который был рожден в индии, и где джава код при старте читал XML, из них генерировал другие XML, XSD, и другой джава код. Это все потом запускалось как сервисы. Кастомеры — всемирно известные концерны-гиганты. Вот от чего надо уходить. Это уже не Ынтырпрайз, это, извините, д****е**зм.
Ребята, я конечно все понимаю, слово крутое, умное и все такое, но может имеется ввиду технологическая сингулярность? А то попахивает диванными экспертами.
Не любое приложение, а только то, которому юзер дал добро. Приложение может даже вайпнуть телефон, если юзер давал ему добро, или тем более занес в Device Administrators. Afaria например.
О, раз уж мы перешли на личности, я смотрю, вы в сказке живете, или как это принято говорить — «по понятиям». Тут одно из двух, либо вы очень легко готовы портить отношение к себе среди знакомых, которым не понять, что такое Private Property, и уж тем более, что такое таргетированный поиск и реклама, персонализация поисковой выдачи итд, потому что не все еще выросли из крестьян. Либо вы безотказны как автомат калашникова и всем даете, кто ни попросит? ;)
PS: Мамы у меня нет.
С xml в target, я и не говорил, что это изящное решение. Я просто сказал, что это возможно, если очень хочется. А вообще, если хочется чего-нибудь такого, нужно остановиться, оглянуться, и подумать еще раз. Скорее всего вы собрались делать что-то не правильно.
Как по мне, это не упростило читабельность кода, а усложнило ее. Убрало «блоки» кода, между которыми я мог фокусировать свое внимание. Меньше строк кода — не значит читабельнее.
Я думаю, Антон читает мыло, так что рано или поздно он тут появится :)
А Мавен своей декларативностью и не-ЯПобразием сразу отбивает все желание самодеяльничать. И тогда в случае необходимости, девелоперы идут к нам. И в большинстве случаев предлагаемое ими решение ущемляет интересы других команд или доменов, и вообще не по фен-шую.
Но ладно, давайте оставим эту тему, я думаю мы друг друга поняли. А как на счет порога вхождения? Мавен — стандарт, найти человека, ориентирующегося в этом стандарте — легко. Грейдл дает нам такой стандарт? Или нам нужно будет придумывать свою архитектуру процесса сборки, а потом каждого новенького кроме всего прочего еще и обучать нашей архитектуре и конвеншнам?
У нас тоже есть свои архитекторы, менеджеры, бэклоги, метрики, лонг-терм гоалы и так далее. Вы думаете, впускать в этот процесс девелоперов хорошо отразиться на общих сроках выполнения задач и метриках? Думаете, девелоперы лучше знать будут, то хорошо для QA и менеджеров? Я думаю, что каждый должен заниматься своим делом. Мы не обслуживающий персонал, призванный ублажать и облегчать жизнь девелоперам, мы такие же девелоперы. И каждый должен делать свою работу.
О его солидном опыте я знаю, мой опыт нервно курит в сторонке. Потому очень жажду дискуссии на эту тему. Хотя, с другой стороны больше половины этого опыта — преподавание в вузе и работа на банк. Я, конечно, не знаю как там у них в Таллине, но есть мнение, что такой опыт заставляет мыслить несколько узковато.
Речь идет немного о другом. Я работал на проекте, который был рожден в индии, и где джава код при старте читал XML, из них генерировал другие XML, XSD, и другой джава код. Это все потом запускалось как сервисы. Кастомеры — всемирно известные концерны-гиганты. Вот от чего надо уходить. Это уже не Ынтырпрайз, это, извините, д****е**зм.
PS: Мамы у меня нет.