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

K>·>Ты тут выше требовал, что тебе непременно нужно 42.7.0, а текущее 42.6.0 тебя не устраивает, т.к. на mvnrepository ты увидел, что вышла новая версия 6 дней назад. Я тоже тебя не понял — зачем, но пытался предложить тебе решение.
K>Я хотел просто актуальную версию
Как это согласуется с "Мне не нужны последние версии библиотек"? Т.е. не нужно, но очень хочется...

K>Это не значит, что мне в старом проекте нужно что-то автоматом подтягивать.
Ну не подтягивай. Я тебе уже показал как можно вручную проверить локально наличие свежего, без автоджобов.

K>·>Уменьшать технический долг. Иначе когда тебе понадобится обновиться, выяснится, что при переходе с очень старой версии на нужную всё сломалось и вообще неясно как чинить.
K>·>Плюс часто это обязуют делать при обнаружении дыр. Тот же mvnrepository ведёт список Vulnerabilities для библиотек.
K>Nuget при сборке выдаёт предупреждение вида:
K>Хочешь — реагируешь, не хочешь — забиваешь.
Как реагировать-то? Вручную? И кто эти варнинги читает и обращает внимание? Это должен быть не варнинг где-то среди сотен-тысяч строк вывода типичного билда, а PR висящий для ревью.

K>·>Как и любой автоматический билд... Или собираешь ты тоже вручную?
K>Каким образом индекс для помощи в наборе xml связан с билдом?
Никак. Ты контекст потерял.

K>Я и без него могу вручную добавить зависимость и билду не нужен этот самый индекс.
Билду и не нужен индекс.

K>·>Индекс для автокомплита, чтобы в процессе набора кода тебе что-то показалось сразу. Апдейт явно провеяет новые версии напрямую.
K>И вот зачем мне эта возня на ровном месте? Что мешало сделать нормально без дополнительныз телодвижений?
Нормально это как? Вручную?

K>·>Эээ.. что за хрень? А какой-нибудь Newtonsoft.Json у себя на серверах собираешь? И Студию?
K>Я не плачу за написание этой библиотеки и пользуюсь теми же публичными пакетами, что и куча других разработчиков.
Ну за Студию-то платишь, надеюсь. И вполне вероятно, что используешь платные библиотеки.

K>·>Т.е. исходников с msbuild-файлом не хватает? Ну это проблема msbuild.
K>Ну, вот у меня был в жизни опыт, когда организация платила за разработку библиотеки.
K>Подрядчик им присылал готовый jar-файл, исходники в каком-то виде присылались.
K>Потом организация решила сама подправить что-то в коде, оказалось, что исходники не собираются, в pom.xml прописаны какие-то серверы подрядчика.
K>Неделю ковырялись, чтобы это в принципе собралось.
Непонятно, почему починкой этого не занялся подрядчик.

K>Чья это проблема была? maven плохой? Или просто нужно контролировать что тебе присылают?
Можно, но не нужно в общем случае. Часто не нужно билды настраивать у себя, так изредка проверить локально, что собирается, если доверия к качеству подрядчика нет.

K>·>Нет, не логично. Или ты gentoo-шник?
K>Ну, доверяй дальше подрядчикам и надейся, что оплаченная разработка в принципе соберётся, а не так, что и деньги потратил и какие-то бинарники есть, а подправить мелкий баг нельзя, т.к. оно не собирается.
Это больше юридическая проблема, чем техническая.

K>·>Разница в том, что будет инфа о том _где_ этот пакет лежит.
K>Это вопрос организации рабочих процессов и в идеале этих вопросов не должно возникать, т.к. подобные вещи должны той же AD настраиваться.
K>У меня вот сейчас есть претензия от админов, что я не в тот репозиторий собираю пакеты.
K>Сейчас они вручную перекинули, но и учётку при этом не дают, чтобы я всё у себя настроил как нужно.
K>Типа потом разберёмся, а пока так пойдёт.
K>И что мне в этом случае даёт знание адреса репозитория?
Это знание зафиксированно в исходнике. Админы у себя баги поправят и ты в исходнике это всё поправишь и будет всё работать по уму, а не через одно место.
Если этого не будет в исходнике, то кто и как об этом будет знать? Куда и как деплоить? Откуда брать зависимости? Как поддерживать и валидировать актуальность этой инфы?

K>·>А в чём тогда проблема-то тогда? Если тебе очень хочется спрятать информацию о репозиториях, чтоб враг не догадался, ты её можешь разместить в settings.xml на каждом конкретном компе, а не в pom.xml самих проектов. Или вообще через командную строку передавать, пока никто не смотрит.
K>В том, что я вижу как на Java все вокруг хардкодят репозитории в pom.xml и им пофиг на возможную смену окружения.
Ну я говорю, что это не обязательно. Репозитории можно в разных местах определять.

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

K>·>Ты тут выше требовал, что тебе непременно нужно 42.7.0, а текущее 42.6.0 тебя не устраивает, т.к. на mvnrepository ты увидел, что вышла новая версия 6 дней назад. Я тоже тебя не понял — зачем, но пытался предложить тебе решение.
K>Я хотел просто актуальную версию
Как это согласуется с "Мне не нужны последние версии библиотек"? Т.е. не нужно, но очень хочется...

K>Это не значит, что мне в старом проекте нужно что-то автоматом подтягивать.
Ну не подтягивай. Я тебе уже показал как можно вручную проверить локально наличие свежего, без автоджобов.

K>·>Уменьшать технический долг. Иначе когда тебе понадобится обновиться, выяснится, что при переходе с очень старой версии на нужную всё сломалось и вообще неясно как чинить.
K>·>Плюс часто это обязуют делать при обнаружении дыр. Тот же mvnrepository ведёт список Vulnerabilities для библиотек.
K>Nuget при сборке выдаёт предупреждение вида:
K>Хочешь — реагируешь, не хочешь — забиваешь.
Как реагировать-то? Вручную? И кто эти варнинги читает и обращает внимание? Это должен быть не варнинг где-то среди сотен-тысяч строк вывода типичного билда, а PR висящий для ревью.

K>·>Как и любой автоматический билд... Или собираешь ты тоже вручную?
K>Каким образом индекс для помощи в наборе xml связан с билдом?
Никак. Ты контекст потерял.

K>Я и без него могу вручную добавить зависимость и билду не нужен этот самый индекс.
Билду и не нужен индекс.

K>·>Индекс для автокомплита, чтобы в процессе набора кода тебе что-то показалось сразу. Апдейт явно провеяет новые версии напрямую.
K>И вот зачем мне эта возня на ровном месте? Что мешало сделать нормально без дополнительныз телодвижений?
Нормально это как? Вручную?

K>·>Эээ.. что за хрень? А какой-нибудь Newtonsoft.Json у себя на серверах собираешь? И Студию?
K>Я не плачу за написание этой библиотеки и пользуюсь теми же публичными пакетами, что и куча других разработчиков.
Ну за Студию-то платишь, надеюсь. И вполне вероятно, что используешь платные библиотеки.

K>·>Т.е. исходников с msbuild-файлом не хватает? Ну это проблема msbuild.
K>Ну, вот у меня был в жизни опыт, когда организация платила за разработку библиотеки.
K>Подрядчик им присылал готовый jar-файл, исходники в каком-то виде присылались.
K>Потом организация решила сама подправить что-то в коде, оказалось, что исходники не собираются, в pom.xml прописаны какие-то серверы подрядчика.
А было бы лучше, если бы просто не собиралось и "не могу найти зависимость"?

K>Неделю ковырялись, чтобы это в принципе собралось.
Непонятно, почему починкой этого не занялся подрядчик.

K>Чья это проблема была? maven плохой? Или просто нужно контролировать что тебе присылают?
Можно, но не нужно в общем случае. Часто не нужно билды настраивать у себя, так изредка проверить локально, что собирается, если доверия к качеству подрядчика нет.

K>·>Нет, не логично. Или ты gentoo-шник?
K>Ну, доверяй дальше подрядчикам и надейся, что оплаченная разработка в принципе соберётся, а не так, что и деньги потратил и какие-то бинарники есть, а подправить мелкий баг нельзя, т.к. оно не собирается.
Это больше юридическая проблема, чем техническая.

K>·>Разница в том, что будет инфа о том _где_ этот пакет лежит.
K>Это вопрос организации рабочих процессов и в идеале этих вопросов не должно возникать, т.к. подобные вещи должны той же AD настраиваться.
K>У меня вот сейчас есть претензия от админов, что я не в тот репозиторий собираю пакеты.
K>Сейчас они вручную перекинули, но и учётку при этом не дают, чтобы я всё у себя настроил как нужно.
K>Типа потом разберёмся, а пока так пойдёт.
K>И что мне в этом случае даёт знание адреса репозитория?
Это знание зафиксированно в исходнике. Админы у себя баги поправят и ты в исходнике это всё поправишь и будет всё работать по уму, а не через одно место.
Если этого не будет в исходнике, то кто и как об этом будет знать? Куда и как деплоить? Откуда брать зависимости? Как поддерживать и валидировать актуальность этой инфы?

K>·>А в чём тогда проблема-то тогда? Если тебе очень хочется спрятать информацию о репозиториях, чтоб враг не догадался, ты её можешь разместить в settings.xml на каждом конкретном компе, а не в pom.xml самих проектов. Или вообще через командную строку передавать, пока никто не смотрит.
K>В том, что я вижу как на Java все вокруг хардкодят репозитории в pom.xml и им пофиг на возможную смену окружения.
Ну я говорю, что это не обязательно. Репозитории можно в разных местах определять.