Про палочки крайне забавно, ибо именно в Корее проблему «зелёных палочек» давно решили за счет преимущественного использования маталлических палочек. Да и куда они собрались сажать эти сосны? (палочки делаются в основном из сибирской сосны)
больше текста там только в заголовке выходит.
имхо наоборот с подсветкой синтаксиса у jspx лучше, да и смешивать его со скриптом нет никакой нужды :) котлеты отдельно.
внутри пустого тега лучше ставить html-comment, конечно, надо об этом помнить.
к плюсам формата могу еще отнести автоматическое вырезание всех whitespaces в итоговой странице
ну я вообще не понимаю ваших проблем :)) такое впечатление, что вы сами себе их придумали, и сами мужественно преодолеваете.
у вас же билд не будет занимать меньше места, если снэпшот станет релизом? если у вас почему-то все разработчики деплоят снэпшоты в общий репозиторий, то почему бы не выделить CI системе отдельный репозиторий с другой политикой очистки?
этим не мавен занимается, а репозиторий артефактов.
собсно, читаем документацию к нексусу, раздел staging repositories, поддерживается в том числе staging snapshots.
как это решено в артифактори не в курсе, наверняка тоже что-то придумали.
да почему же нет? у нас по две недели лежат все снэпшоты в нексусе и дженкинсе. надо было бы дольше — лежали бы хоть год, винты стоят копейки.
«быстро расследовать» обычно значит что проблема вот она — появилась с последним коммитом. чего там расследовать? если оно косвенно всплыло из-за кода другого модуля (а это уже реже встречается) берем и смотрим сразу fisheye activity, ибо конкретные версии артефактов тут не спасут. может причина косвенной проблемы в коде другого модуля появилась неделю назад и тесты тогда не падали.
>Со снепшот зависимостью билд проекта не воспроизводим; нет информации, какая именно зависимость в него вошла
да вообще-то есть, тот самый вами нелюбимый Jenkins прямо ссылочки проставляет на все зависимые снэпшоты и т.д.
я уж молчу, что CI он на то и CI чтобы как можно раньше проблемы ловить. какой смысл расследовать проблему пять снэпшотов назад?
>Но как часто встречается такая ситуация? Редко
да как бы мой опыт говорит ровно наоборот. Если проект стабилен и в нём только вялый багфикс, тогда да. А если проект живой, то даже будучи отнюдь не стартапом основные модули постоянно перетряхиваются, включая интерфейсы. Обычно есть 3-4 core util артефакта, в которых только вялые фиксы, такие артефакты включаются версиями, а не снэпшотами и их изменения, если что, могут и подождать.
ниасилил, чем вам снэпшоты не угодили. чтобы не ползать по куче модулей, меняя версии перекрёстных зависимостей перед релизом, есть master-pom или какой-то parent-pom.
версии самих артефактов меняет релиз плагин.
не, «побеждения» тоже заканчиваются и наступают суровые будни.
исследования магического мира весьма тяжело придумать так, чтобы они не разрушили сюжет и не дали герою уж совсем много могущества. так что автор уж ограничивает его, как может.
:))) но вообще, курица — это главное, что запомнилось и что захотелось попробовать добавить к уже имеющемуся CI процессу.
жаль, что команда распределённая и не все получат свою долю радости
да какие там наработки, ставьте nexus в качестве прокси репозитория, деплоите на него свои артефакты и живёте — не тужите.
в книгах всё написано, правда, на английском.
имхо наоборот с подсветкой синтаксиса у jspx лучше, да и смешивать его со скриптом нет никакой нужды :) котлеты отдельно.
внутри пустого тега лучше ставить html-comment, конечно, надо об этом помнить.
к плюсам формата могу еще отнести автоматическое вырезание всех whitespaces в итоговой странице
у вас же билд не будет занимать меньше места, если снэпшот станет релизом? если у вас почему-то все разработчики деплоят снэпшоты в общий репозиторий, то почему бы не выделить CI системе отдельный репозиторий с другой политикой очистки?
собсно, читаем документацию к нексусу, раздел staging repositories, поддерживается в том числе staging snapshots.
как это решено в артифактори не в курсе, наверняка тоже что-то придумали.
«быстро расследовать» обычно значит что проблема вот она — появилась с последним коммитом. чего там расследовать? если оно косвенно всплыло из-за кода другого модуля (а это уже реже встречается) берем и смотрим сразу fisheye activity, ибо конкретные версии артефактов тут не спасут. может причина косвенной проблемы в коде другого модуля появилась неделю назад и тесты тогда не падали.
да вообще-то есть, тот самый вами нелюбимый Jenkins прямо ссылочки проставляет на все зависимые снэпшоты и т.д.
я уж молчу, что CI он на то и CI чтобы как можно раньше проблемы ловить. какой смысл расследовать проблему пять снэпшотов назад?
>Но как часто встречается такая ситуация? Редко
да как бы мой опыт говорит ровно наоборот. Если проект стабилен и в нём только вялый багфикс, тогда да. А если проект живой, то даже будучи отнюдь не стартапом основные модули постоянно перетряхиваются, включая интерфейсы. Обычно есть 3-4 core util артефакта, в которых только вялые фиксы, такие артефакты включаются версиями, а не снэпшотами и их изменения, если что, могут и подождать.
версии самих артефактов меняет релиз плагин.
исследования магического мира весьма тяжело придумать так, чтобы они не разрушили сюжет и не дали герою уж совсем много могущества. так что автор уж ограничивает его, как может.
жаль, что команда распределённая и не все получат свою долю радости
Что такое регистрация изменений? Commit?
примеров везде навалом, берете любой опенсорс проект и смотрите, что там в мастер-поме и что в подмодулях.
в книгах всё написано, правда, на английском.