Здравствуйте, Cyberax, Вы писали:

C>Вот весь смысл в том, что для Java у меня всё нужное есть в OpenSource.
Весь смысл в том, что обычно когда разрабатывают коммерческий софт решение по использованию кажой библиотеки принимается осознанно. Как с точки зрения лицензирования, так и с точки зрения целесообразности использования.

C>Работоспособность приложения проверяется QA-шниками, конкретные версии зависимых библиотек тут не важны. Посмотреть что именно загрузилось, конечно, не мешает (хотя бы раз), но потом об этом особо можно не заботиться.
Ты что-нибудь про юнит-тесты, например, слышал, надеюсь? Как вы обеспечиваете покрытие тестами всего этого накаченного зоопарка?

C>А что не так с разделением зон ответственности?
Ну как что? Классический расклад: "А включаешь -- не работает". При этом не работает не совсем в твоём коде или совсем не в твоём. Кто и как ищет и фиксит багу, особенно если часть используемого кода проприетарная и в исходниках не доступна?
Опять же как осуществляется поддержка этой конструкции, особенно если у вас заявлены таймауты на реакцию?..

Здравствуйте, Cyberax, Вы писали:

C>Нет в MSBuild транзитивного управления зависимостями с поддержкой загрузки недостающих артефактов из репозиториев. Точнее, это можно всё руками сделать — как можно сделать всё и на чистом make.

Главное не забыть прикрутить прогресс-бар: "А теперь вы должны XXX килобаксов"
Кстати, темаинтересная. Надо такой тулл таки заботать, и паразитировать на финансовых потоках + продавать места в списках ссылок на репозитории...

Здравствуйте, Cyberax, Вы писали:

C>Appliance в 5Гб зато хорошо показывает подход MS.
Да это всего лишь показывает, что у клиентов, на которых это расчитано толстый канал, да и только...
Нам 5 Гб выкачать не особо трудно, например...

Здравствуйте, Erop, Вы писали:

C>>Управлять всем этим вручную? Ну нафиг.
E>А просто зависеть от всего этого?
Так оно от этого всего и зависит. Но позволяет нормально структурировать зависимости.

E>Просто для OS такой подход органичен, для коммерческого проприетарного софта неудобен. Это не значит, что какой-то из подходов лучше или "для ламеров" или ещё что...
Нормально удобен. Внутри организации у меня свой приватный репозиторий (с контролем доступа и т.п.), куда публикуются модули, которые точно так же прилинковываются к нужным проектам.

Здравствуйте, Erop, Вы писали:

C>>Нет в MSBuild транзитивного управления зависимостями с поддержкой загрузки недостающих артефактов из репозиториев. Точнее, это можно всё руками сделать — как можно сделать всё и на чистом make.
E>Главное не забыть прикрутить прогресс-бар: "А теперь вы должны XXX килобаксов"
Зачем? Сразу номер карточки в настройках тулзы указывать.

E>Кстати, темаинтересная. Надо такой тулл таки заботать, и паразитировать на финансовых потоках + продавать места в списках ссылок на репозитории...
Maven уже так умеет — просто отделяешь библиотеку и лицензионный ключ для неё.

Здравствуйте, Erop, Вы писали:

C>>Appliance в 5Гб зато хорошо показывает подход MS.
E>Да это всего лишь показывает, что у клиентов, на которых это расчитано толстый канал, да и только...
E>Нам 5 Гб выкачать не особо трудно, например...
Мне тоже. Но это показывает общее небрежное отношение к объёмам и ресурсам.

Здравствуйте, Erop, Вы писали:

C>>Вот весь смысл в том, что для Java у меня всё нужное есть в OpenSource.
E>Весь смысл в том, что обычно когда разрабатывают коммерческий софт решение по использованию кажой библиотеки принимается осознанно. Как с точки зрения лицензирования, так и с точки зрения целесообразности использования.
В Maven для этого специально есть http://maven.apache.org/plugins/maven-project-info-reports-plugin/license-mojo.html . Всё продумано!

C>>Работоспособность приложения проверяется QA-шниками, конкретные версии зависимых библиотек тут не важны. Посмотреть что именно загрузилось, конечно, не мешает (хотя бы раз), но потом об этом особо можно не заботиться.
E>Ты что-нибудь про юнит-тесты, например, слышал, надеюсь? Как вы обеспечиваете покрытие тестами всего этого накаченного зоопарка?
Зачем мне тестировать зарелизенные версии библиотек? Хотя, при желании, как раз, с Maven'ом это сделать совсем несложно.

Мой код прекрасно тестируется с помощью как раз этого Maven'а. Заодно Maven сам строит отчёты о тестировании: http://maven.apache.org/plugins/maven-surefire-report-plugin/ При желании туда ещё одним движением руки подключается code coverage.

C>>А что не так с разделением зон ответственности?
E>Ну как что? Классический расклад: "А включаешь -- не работает". При этом не работает не совсем в твоём коде или совсем не в твоём. Кто и как ищет и фиксит багу, особенно если часть используемого кода проприетарная и в исходниках не доступна?
Тут как раз оно очень удобно. Шаги такие:
1) Ищем предыдущую версию, которая работала.
2) Генерируем отчёт о зависимостях (как ни странно, с помощью одной команды Maven).
3) Смотрим что поменялось.
4) Смотрим кто поменял.
5) Бьём его по наглой рыжей морде.

Особенно удобно, когда разные модули проекта, которые пишут разные команды, тоже управляются Maven'ом.

E>Опять же как осуществляется поддержка этой конструкции, особенно если у вас заявлены таймауты на реакцию?..
А какие проблемы?

Здравствуйте, Cyberax, Вы писали:

C>Зачем мне тестировать зарелизенные версии библиотек? Хотя, при желании, как раз, с Maven'ом это сделать совсем несложно.
Круто!!! Ничего про баги в ПО не слышал?

E>>Ну как что? Классический расклад: "А включаешь -- не работает". При этом не работает не совсем в твоём коде или совсем не в твоём. Кто и как ищет и фиксит багу, особенно если часть используемого кода проприетарная и в исходниках не доступна?
C>Тут как раз оно очень удобно. Шаги такие:
C>1) Ищем предыдущую версию, которая работала.
C>Особенно удобно, когда разные модули проекта, которые пишут разные команды, тоже управляются Maven'ом.

А если такой версии не было никогда. Просто вновь обнаруженная бага. Или вопросы поддержки пользователей у вас вообще не рассматриваются?

E>>Опять же как осуществляется поддержка этой конструкции, особенно если у вас заявлены таймауты на реакцию?..
C>А какие проблемы?

Ну как это всё происходит организационно, интересно. Вот, скажем, надо вам реагировать в течении рабочего дня...
Бага, по твоему мнению находится в третьем поколении зависимостей. А фиксить надо либо там, либо во втром поколении зависимостей. И что делаем дальше?

Здравствуйте, Cyberax, Вы писали:

E>>А просто зависеть от всего этого?
C>Так оно от этого всего и зависит. Но позволяет нормально структурировать зависимости.
Так вот и не хочется зависить от ТАКОГО количества смежников...

E>>Просто для OS такой подход органичен, для коммерческого проприетарного софта неудобен. Это не значит, что какой-то из подходов лучше или "для ламеров" или ещё что...
C>Нормально удобен. Внутри организации у меня свой приватный репозиторий (с контролем доступа и т.п.), куда публикуются модули, которые точно так же прилинковываются к нужным проектам.
Так это у вас внутри конторы такие кустистые зависимости?

Здравствуйте, Cyberax, Вы писали:

E>>Нам 5 Гб выкачать не особо трудно, например...
C>Мне тоже. Но это показывает общее небрежное отношение к объёмам и ресурсам.

Зато инсталляция, скорее всего похожа на реальную, а не на минималлистическую. Почему тебе кажется, что время сотрудников менее ценно, чем трафик?..

Здравствуйте, Erop, Вы писали:

C>>Зачем мне тестировать зарелизенные версии библиотек? Хотя, при желании, как раз, с Maven'ом это сделать совсем несложно.
E>Круто!!! Ничего про баги в ПО не слышал?
А они находятся test-case'ами? Но Maven и в поиске багов помогает, IDEA сама мне скачает исходники используемых библиотек и подключит в проект. То есть, я прямо без всяких проблем могу отлаживать код библиотек.

C>>Особенно удобно, когда разные модули проекта, которые пишут разные команды, тоже управляются Maven'ом.
E>А если такой версии не было никогда. Просто вновь обнаруженная бага. Или вопросы поддержки пользователей у вас вообще не рассматриваются?
А если новая бага — то всё как обычно: дебаггер в руки, находим причину бага, фиксим. Если бага во внешней библиотеке — делаем workaround для неё, или создаём приватную версию с фиксом и кладём в свой репозиторий (параллельно пиная разработчиков библиотеки, чтобы включили фикс в следующий релиз).

C>>А какие проблемы?
E>Ну как это всё происходит организационно, интересно. Вот, скажем, надо вам реагировать в течении рабочего дня...
У меня обычно время реакции ещё меньше — считанные часы для критичных фиксов...

E>Бага, по твоему мнению находится в третьем поколении зависимостей. А фиксить надо либо там, либо во втром поколении зависимостей. И что делаем дальше?
Фиксим зависимость и делаем для неё override. Примерно так:

            <dependency>
                <groupId>jasperreports</groupId>
                <artifactId>jasperreports</artifactId>
                <version>2.0.2</version>
                <!-- XML APIs are broken because of conflict with root classloader -->
                <exclusions>
                    <exclusion>
                        <groupId>xml-apis</groupId>
                        <artifactId>xml-apis</artifactId>
                    </exclusion>
                </exclusions>
            </dependency>
            <!-- Manually override XML APIs version -->
            <dependency>
                <groupId>xml-apis</groupId>
                <artifactId>xml-apis</artifactId>
                <version>1.3.02</version>
            </dependency>

На практике, багов с зависимостями в рантайме у меня пока (к счастью) не было.

Здравствуйте, Erop, Вы писали:

C>>Так оно от этого всего и зависит. Но позволяет нормально структурировать зависимости.
E>Так вот и не хочется зависить от ТАКОГО количества смежников...
Ну так а что делать, если эти зависимости реально нужны? Основной другой вариант — свалить всё в кучу и молиться, чтоб работало.

C>>Нормально удобен. Внутри организации у меня свой приватный репозиторий (с контролем доступа и т.п.), куда публикуются модули, которые точно так же прилинковываются к нужным проектам.
E>Так это у вас внутри конторы такие кустистые зависимости?
У нас пока ещё не очень. В приватном репозитории лежат, в основном, только несколько чисто утиллитных проектов. Но к этому движется, да.

Здравствуйте, Erop, Вы писали:

C>>Мне тоже. Но это показывает общее небрежное отношение к объёмам и ресурсам.
E>Зато инсталляция, скорее всего похожа на реальную, а не на минималлистическую. Почему тебе кажется, что время сотрудников менее ценно, чем трафик?..
У меня тоже вполне реальная инсталляция. Если настроить компоненты — то можно сразу работать с ней. По возможностям, кстати, функционала будет не меньше, чем в TFS.

Здравствуйте, Cyberax, Вы писали:

E>>Бага, по твоему мнению находится в третьем поколении зависимостей. А фиксить надо либо там, либо во втром поколении зависимостей. И что делаем дальше?

C>Фиксим зависимость и делаем для неё override. Примерно так:

dependencyManagement в таком случае разве не поможет? Должен перекрыть версию.

Здравствуйте, WFrag, Вы писали:

C>>Фиксим зависимость и делаем для неё override. Примерно так:
WF>dependencyManagement в таком случае разве не поможет? Должен перекрыть версию.
Проще явно сделать руками, более красиво выглядит.

Здравствуйте, Cyberax, Вы писали:

C>IDEA сама мне скачает исходники используемых библиотек и подключит в проект. То есть, я прямо без всяких проблем могу отлаживать код библиотек.
C>А если новая бага — то всё как обычно: дебаггер в руки, находим причину бага, фиксим. Если бага во внешней библиотеке — делаем workaround для неё, или создаём приватную версию с фиксом и кладём в свой репозиторий (параллельно пиная разработчиков библиотеки, чтобы включили фикс в следующий релиз).
E>>Бага, по твоему мнению находится в третьем поколении зависимостей. А фиксить надо либо там, либо во втром поколении зависимостей. И что делаем дальше?
C>Фиксим зависимость и делаем для неё override. Примерно так:

А если всё-таки вернуться к ситуации, когда библиотеки проприетарные и код их не доступен, а редестрибуция своих версий невозможна?
Ты же в этих условиях все эти фичи заюзать советуешь, или ты всё только о мире OS говоришь?
Правда править чужую непростую либу я и сам не хотел бы, безотносительно к лицензиям. Вот, скажем, есть такая распознавалка "клинопись", у неё есть тулкит. Работает нестабильно. Отлаживать я бы не взялся, даже при доступных исходниках...

C>На практике, багов с зависимостями в рантайме у меня пока (к счастью) не было.
Ну и хорошо. Хотя это для меня странно. А у тебя какой цикл разработки (сколько времени между версиями проходит). У наукоёмкого софта это годы...

Здравствуйте, Cyberax, Вы писали:

C>Ну так а что делать, если эти зависимости реально нужны? Основной другой вариант — свалить всё в кучу и молиться, чтоб работало.
Что значит "реально нужны"? Обычно смежники дороже разработчиков обходятся...

E>>Так это у вас внутри конторы такие кустистые зависимости?
C>У нас пока ещё не очень. В приватном репозитории лежат, в основном, только несколько чисто утиллитных проектов. Но к этому движется, да.
Ну когда стаент всё так "хорошо" поделишься опытом управления этим зоопарком и механизмами разрешения конфликтов интересов...

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Cyberax, Вы писали:

C>>Ну так а что делать, если эти зависимости реально нужны? Основной другой вариант — свалить всё в кучу и молиться, чтоб работало.
E>Что значит "реально нужны"? Обычно смежники дороже разработчиков обходятся...

Наши Java приложения процентов на 90%, наверное, из OS библиотек и фреймворков обычно состоят. При этом эти OS библиотеки и фреймворки, как правило, по качеству гораздо лучше того, что делаем мы сами. Просто потому что их использует масса народу, включая монстров типа IBM. Либо они написаны грамотными разработчиками (тот же GWT).

Здравствуйте, WFrag, Вы писали:

WF> При этом эти OS библиотеки и фреймворки, как правило, по качеству гораздо лучше того, что делаем мы сами.
Меня терзают смутные сомненья. Сколько OS фреймворков не видел, в большинстве случаев качество ниже плинтуса и никто ни за что не отвечает.

WF> Просто потому что их использует масса народу, включая монстров типа IBM.
Обожемой, это первый признак того, что ни в коем случае использовать это нельзя..

WF>Либо они написаны грамотными разработчиками (тот же GWT).
А вы не грамотные что ли? =)

Здравствуйте, WFrag, Вы писали:

WF>Наши Java приложения процентов на 90%, наверное, из OS библиотек и фреймворков обычно состоят. При этом эти OS библиотеки и фреймворки, как правило, по качеству гораздо лучше того, что делаем мы сами. Просто потому что их использует масса народу, включая монстров типа IBM. Либо они написаны грамотными разработчиками (тот же GWT).

Прикольно, как это взаимосоотносится с тезисом Цайберакса о том, что Ява для людей пишуших мегастройный код, а C# для кодеров начального уровня...
Хотя мне вот тоже кажется, что вся методология работы с Мавином построена на том, что библиотеки намного лучше реализованы, чем прикладной код...