Также нашел тезисы, прочитал и не удержался, написал свой отзыв. Сильно напомнило о проблемах, с которыми сам сталкивался по работе. Народ работает на стыке управления конфигурациями ПО (контроля версий), проектирования систем и управления проектами. Не просто складывают софт из кирпичиков-компонент (это задача обычная), но и управляют конфигурациями этих кирпичиков, т.е. отслеживают версии, ответвления и зависимости компонент друг от друга.
Очень понравилось.
Наверняка кто-то из присутствующих занимался или применял что-либо подобное. Рассказывайте, не стесняйтесь.
Здравствуйте, iZEN, Вы писали:
ZEN>См. Continuous Integration.
Это абсолютно из другой области. CI и то, о чем статья — вещи ортогональные друг другу. Т.е. компонентная высокоуровневая сборка может иметь в основе CI, и CI может быть использована при разработке компонент, однако в статье описана значительно более сложная инфраструктура.
Здравствуйте, Aquary, Вы писали:
A>Здравствуйте, iZEN, Вы писали:
iZEN>>См. Continuous Integration.
A>Это абсолютно из другой области. CI и то, о чем статья — вещи ортогональные друг другу. Т.е. компонентная высокоуровневая сборка может иметь в основе CI, и CI может быть использована при разработке компонент, однако в статье описана значительно более сложная инфраструктура.
Что вы хотите получить на выхлопе?
Re[4]: Отличная статья о сборке продуктов промышленного уров
Здравствуйте, Aquary, Вы писали:
A>Здравствуйте, iZEN, Вы писали:
iZEN>>Что вы хотите получить на выхлопе?
A>Не совсем понял вопрос.
Какую цель вы преследуете? Какое решение вы хотите получить? (ответ "работающее" слишком общ). Чего вам не хватает в существующих решениях? (одна кнопка "Сделать зашибись" — это слишком просто).
Re[6]: Отличная статья о сборке продуктов промышленного уров
Здравствуйте, iZEN, Вы писали:
ZEN>Какую цель вы преследуете?
Рассказать о разработках, о которых рассказали граждане скандинавы.
ZEN>Какое решение вы хотите получить?
Пока — никакое. Граждане скандинавы хотят.
ZEN>(ответ "работающее" слишком общ). Чего вам не хватает в существующих решениях? (одна кнопка "Сделать зашибись" — это слишком просто).
Но если бы я был на их месте... А я частично был на их месте, т.к. работал с похожими технологиями...
В общем, хотелось бы получить решение, которое делает то, что они описывают. А именно — дать на вход описание версий компонент, указать зависимости, дать на вход описание нужной мне конфигурации. И далее — получить сборку системы, которая мне нужна. Или же получить объяснение — какие компоненты с какими другими компонентами не сочетаются и почему. Это если вкратце.
Задача очень общая, да. Но класс таких задач существует и был бы востребован в продуктах, которые требуют частой модификации под разных клиентов.
Здравствуйте, Aquary, Вы писали:
iZEN>>(ответ "работающее" слишком общ). Чего вам не хватает в существующих решениях? (одна кнопка "Сделать зашибись" — это слишком просто).
A>Но если бы я был на их месте... А я частично был на их месте, т.к. работал с похожими технологиями... A>В общем, хотелось бы получить решение, которое делает то, что они описывают. А именно — дать на вход описание версий компонент, указать зависимости, дать на вход описание нужной мне конфигурации. И далее — получить сборку системы, которая мне нужна. Или же получить объяснение — какие компоненты с какими другими компонентами не сочетаются и почему. Это если вкратце. A>Задача очень общая, да. Но класс таких задач существует и был бы востребован в продуктах, которые требуют частой модификации под разных клиентов.
Порты FreeBSD устроят? Apache Maven устроит?
Каждый день пользуемся.
Re[8]: Отличная статья о сборке продуктов промышленного уров
Здравствуйте, Aquary, Вы писали:
A>Здравствуйте, iZEN, Вы писали:
iZEN>>Порты FreeBSD устроят? A>При чем здесь они?
Как причём? Они обеспечивают кастомную конфигурацию, сборку, инсталляцию и целостность рантайма пользовательского окружения.
iZEN>> Apache Maven устроит? A>Это может быть нижним уровнем подобного решения, в статье же речь идет о более высокоуровневой концепции.
Вам не нравятся ни порты FreeBSD, ни Maven. Так что вам нужно в итоге? Что за такие "высокоуровневые концепции", которые не совпадают (интересно, в чём?) с видениями разработчиков выше приведённых реально работающих инструментов?
Re[10]: Отличная статья о сборке продуктов промышленного уро
Здравствуйте, iZEN, Вы писали:
ZEN>Вам не нравятся ни порты FreeBSD, ни Maven.
В портах всё заточено для работы под той же FreeBSD. Сборка продукта под другую платформу, я так понимаю, невозможна.
Maven близок к идее, высказанной авторами.
ZEN>Так что вам нужно в итоге?
Тот самый конфигуратор из статьи. Чтобы умел отслеживать версии компонент (с возможными ветвлениями) и их зависимости между собой.
В том же Мэйвене надо говорить — "хочу собрать компонент 1 версии 2.5, но учти, что у него зависимость от компонента 2, версии 1.3. Жги."
У сферического коня в вакууме будет база компонент со список реализованных в них фич, их версий, граф зависимостей. После чего пользователю можно будет сказать — "хочу фичи A, B, C плюс компоненту для работы с форматом данных XZ", далее инструмент подберет нужные компоненты в нужных версиях, с учетом зависимостей и ответствелий — ну и далее всё то, что умеет делать и Мэйвен.
Здравствуйте, Aquary, Вы писали:
A>Тот самый конфигуратор из статьи. Чтобы умел отслеживать версии компонент (с возможными ветвлениями) и их зависимости между собой. A>В том же Мэйвене надо говорить — "хочу собрать компонент 1 версии 2.5, но учти, что у него зависимость от компонента 2, версии 1.3. Жги."
Не понял о чем речь. В maven я подключу нужный мне компонент, а все остальные по зависимостям будут подключены.
A>У сферического коня в вакууме будет база компонент со список реализованных в них фич,
И как эта база хранится будет? Очевидно, что в каком-то виде, предназначенном в первую очередь для человека. То есть по сути это:
* Домашнии страницы библиотека;
* Гугл как поисковое средство по нима (ну или что-то типа java-source.net или dev.java.net
* Репозиторий maven, в котором берутся артефакты с прописанными зависимостями.
Здравствуйте, LeonidV, Вы писали:
LV>И как эта база хранится будет? Очевидно, что в каком-то виде, предназначенном в первую очередь для человека. То есть по сути это:
Нет, храниться может как угодно. Представлено наружу — да, в человеческом виде LV>* Домашнии страницы библиотека; LV>* Гугл как поисковое средство по нима (ну или что-то типа java-source.net или dev.java.net
Нет, этого будет недостаточно. Нужно привязать фичи к компонентам, а точнее определенным версиям.
LV>* Репозиторий maven, в котором берутся артефакты с прописанными зависимостями.
Я уже говорил — Maven вполне может быть частью подобного решения. Но его одного недостаточно.
LV>Я так в лоб спрошу — вы с maven работали?
Здравствуйте, Aquary, Вы писали:
LV>>И как эта база хранится будет? Очевидно, что в каком-то виде, предназначенном в первую очередь для человека. То есть по сути это: A>Нет, храниться может как угодно. Представлено наружу — да, в человеческом виде
Если представление для человека, зачем тогда хранить как-то иначе?
A>Нет, этого будет недостаточно. Нужно привязать фичи к компонентам, а точнее определенным версиям.
Ну идем на домашнюю страницу и смотрим changelog. Подключаем нужную версию библиотеки через maven.
Вообще, как правило к версиям библиотек привязывают не фичи, а баги или зависимости от других библиотек. Обычно самая свежая версия являются нормальным выбором.
A>Знакомился. В работе не использовал.
Ясно. Значит это из серии "посмотрел обложку, не читал, осуждаю".
Здравствуйте, LeonidV, Вы писали:
LV>Если представление для человека, зачем тогда хранить как-то иначе?
Для простоты привязки к другим данным.
LV>Ну идем на домашнюю страницу и смотрим changelog. Подключаем нужную версию библиотеки через maven.
А если нужна определенная версия компоненты или ичи — то ищет предыдущий ченджлог, а потом ещё один, более ранний и т.п.? Такие вещи нельзя делать руками — просто потому что это офигеннейший потенциальный источник ошибок.
LV>Вообще, как правило к версиям библиотек привязывают не фичи, а баги или зависимости от других библиотек.
Что баги, что фичи — это в терминах SCM — запросы на изменение. К подоюным запросам относят и изменения по рефакторингу, к слову.
LV>Обычно самая свежая версия являются нормальным выбором.
Насчет самой последней — не факт. Простейший пример — зависимости, которые ещё не подошли в основную кодовую базу продукта, а лишь лежат на ветках у команды разработки. Для отгрузки тестерам — вполне подойдет. Для отгрузки кастомеру — никак.
В своих комментариях к статье я уже указал, что задачи у авторов продиктованы в первую очередь нуждами компании-производителя сотовых. По своему опыту в этой индустрии знаю, что вариаций одного продукта может быть уйма. И версии компонент и включенные в них фичи могут быть самыми разнообюразными.
A>>Знакомился. В работе не использовал. LV>Ясно. Значит это из серии "посмотрел обложку, не читал, осуждаю".
Ну, во-первых "Пастернака не читал, но осуждаю".
Во-вторых, приведите мне цитату, где я осуждал Мэйвена?
В-третьих, не обязательно юзать продукт несколько лет, чтобы знать — чего он не умеет. Это становится ясно после даже беглого знакомства.
Я понял, о чем вы говорите. Сознаюсь, особо ветку не читал (ага, прям как сам написал). У вас специфика проекта заключается в поддержке одной версии ПО на различном АО. Тут наверное и правда maven'а будет мало. Для других задача вся инфраструктура готова в том виде, как я описал ранее (гугл+maven). Просто я сам описанные задачи (поиск решения и подключения) решаю именно таким образом и достаточно эффективно.
Здравствуйте, Aquary, Вы писали:
A>Здравствуйте, iZEN, Вы писали:
iZEN>>Вам не нравятся ни порты FreeBSD, ни Maven.
A>В портах всё заточено для работы под той же FreeBSD. Сборка продукта под другую платформу, я так понимаю, невозможна.
Ну, в портах возможна конфигурация и установка плагинов под Eclipse, а это уже "другая" платформа.
Re[2]: Отличная статья о сборке продуктов промышленного уров
Здравствуйте, TimurSPB, Вы писали:
TSP>Хм. А где статья? Отличное краткое содержание статьи о сборке продуктов промышленного уровня это маловато для обсуждения.
Возможно, погорячился насчет "статья" в сабж — речь идет о тезисах к выступлению на конференции (я там ещё ссылку на бложик дал). Хотя по мне — так полноценная вводная статья в проблематику. Сильно хочу поискать ещё их материалов, как с текучкой разгребусь.
Да, релизнотов я сам в своё время много написал
LV>Я понял, о чем вы говорите. Сознаюсь, особо ветку не читал (ага, прям как сам написал). У вас специфика проекта заключается в поддержке одной версии ПО на различном АО. Тут наверное и правда maven'а будет мало.
Да, и не просто одной версии, а нескольких версий для различных кастомеров... Местами голова кругом шла...
LV>Для других задача вся инфраструктура готова в том виде, как я описал ранее (гугл+maven). Просто я сам описанные задачи (поиск решения и подключения) решаю именно таким образом и достаточно эффективно.
Здравствуйте, Aquary, Вы писали:
A>Здравствуйте, iZEN, Вы писали:
iZEN>>Ну, в портах возможна конфигурация и установка плагинов под Eclipse, а это уже "другая" платформа.
A>Напильник там не прилагается часом?
/usr/ports/UPDATING — там всё написано, где что подрихтовать и подточить.
Да, с эклипсом там хоть что написать можно, спору нет 
Местами голова кругом шла...