Как чем не угодил?
Тем, что он не менеджер конфликтов и не отключатель конфликтов:) Он просто de-facto отключает транзитивные зависимости, но только для тех артефактов, которые вы там прописали!
Т.е. если вы там прописали D — молодец! А если, то держи nearest, и не жалуйся!
Это же ни рыба, ни мясо — вы не знаете, что там писать, и уж точно не знаете, когда случается конфликт, пока что-то не перестанет работать (Мерфи подсказывает — в продакшне).
Я-ж не говорил, что с Maven-ом нельзя :)
У меня спросили, что бы я посоветовал. Я бы посоветовал выбрать лучшую систему сборки, но с очень легким переходом с Ant-а. Лучше-ж быть здоровым, но богатым, чем бедным, но больным, правда?
Вот это дельная идея. Только не очень масштабируемая :) Я вам расскажу, что Gradle вплоть до относительно поздних версий (0.5, что-ли) вообще по дефолту шёл с отключенной транзитивностью. А потом его начали использовать в энтерпрайзе :D
Безусловно, нужен контроль за новыми зависимостями. Не только из-за того, что «кака», но из-за виральных лицензий, например. Есть инструменты, например Artifactory, с помощью которых можно очень легко отслеживать изменения зависимостей после каждой сборки.
Так что я считаю, что транзитивность можно оставить, но стратегия fail + контроль за изменениями — это наше всё.
Я бы посоветовал неспешно перееезжать на Грейдл. В случае с Антом это очень легко, и постепенно. Можно сначала обвернуть вообще весь существующий скрипт в Грейдл, и потихоньку выдирать из Анта таргеты и прописывать их Грейдле. Одно удовольствие. Читать тут. (С Мавеном, к сожалению, такая штука не пройдет, в частности из-за того, что при конфликтах транзитивных зависимостей Мавен ведет себя так, как ведет).
Ваше заявление, что раз Maven просто инструмент, то я должен бросить обращать внимание на его WTF-нуть странно :)
Если я вам дам нож с лезвиями в обе стороны и без рукоятки, то вы тоже решите, что раз это просто инструмент, то с ним все ОК? :)
Я-ж не говорил, что в Maven-е проблема не решается вообще. Я конкретно упомянул dependency/exclusions и сказал про них, что
Это хороший выход, конфликта больше нет, D2 в classpath, win.
Проблема этими решением что слегка устанете 1. находить конфликты без fail. 2 exclude-ить их ручками. Причем, чем больше проект, тем сильнее устанете. Не масштабируемо.
Я совершенно не согласен с тем, что решение для jar hell — osgi. Он идеально подходит в случаях, когда несколько версий одного класса необходимы (например, pluggable софт). Но пользоваться им просто потому что ваш инструмент сборки коряв и не может дать вам нормального решения конфликтов? Overkill-чик.
Черт, так и знал, что надо написать про enforcer plugin. Ну ладно, здесь напишу.
И так, что мы имеем с гуся?
Мы имеем чудесный rule, под обманчивым названием bannedDependencies, которое можно понять как «эти зависимости мы запретим». А вот и нет. Это означает «это запрещенные зависимости, на них мы упадем». «Так это-же твоя любимая стратегия fail!» воскликнут неумные среди нас, и будут не правы. Стратегия fail роняет сборку при наличии конфликта, а enforcer роняет при наличии конкретно прописанной зависимости.
Обратите внимание на использованные библиотеки в примере (он с сайта плагина) — commons-logging, log4j! Они запрещены не из-за конфликтов версий, а из-за конфликтов библиотек! Про мотивацию и исполнение запретов такого вида читать тут (инглиш).
Да, про Spark я забыл. Тоже клон Синтары. Мне кажется преимущество Ratpack-а в том, что он не только Java. Я очень рекомендую делать проектик именно на нем, даже если начнете с Джавы, потому-что постепенно переползете на Груви, и ни разу не пожалеете :)
Jersey и RESTlet заточены на построение REST APIs. Можно, конечно их абьюзить как веб-фреймоврки, но зачем? Про Spark ответил выше. Sitebriks прикольный, раньше не видел, сейчас добавлю в статью.
Вот почему да:
На этот класс нигде в коде больше не ссылаются, так что никаких конфликтов не будет. Зато для ознакомительного материала это очень удобно, можно показать о каком классе фреймворка идёт речь без копания в импортах. Самое гавное — хорошие названия ценны, особенно в таких статьях. Зачем отказываться?
Тем, что он не менеджер конфликтов и не отключатель конфликтов:) Он просто de-facto отключает транзитивные зависимости, но только для тех артефактов, которые вы там прописали!
Т.е. если вы там прописали D — молодец! А если, то держи nearest, и не жалуйся!
Это же ни рыба, ни мясо — вы не знаете, что там писать, и уж точно не знаете, когда случается конфликт, пока что-то не перестанет работать (Мерфи подсказывает — в продакшне).
P.S. Спасибо за комплимент, буду раз вас видеть!
У меня спросили, что бы я посоветовал. Я бы посоветовал выбрать лучшую систему сборки, но с очень легким переходом с Ant-а. Лучше-ж быть здоровым, но богатым, чем бедным, но больным, правда?
Безусловно, нужен контроль за новыми зависимостями. Не только из-за того, что «кака», но из-за виральных лицензий, например. Есть инструменты, например Artifactory, с помощью которых можно очень легко отслеживать изменения зависимостей после каждой сборки.
Так что я считаю, что транзитивность можно оставить, но стратегия fail + контроль за изменениями — это наше всё.
Вся эта прелесть, and more, будет по русски в Питере буквально в субботу!
Если я вам дам нож с лезвиями в обе стороны и без рукоятки, то вы тоже решите, что раз это просто инструмент, то с ним все ОК? :)
Я-ж не говорил, что в Maven-е проблема не решается вообще. Я конкретно упомянул dependency/exclusions и сказал про них, что
Проблема этими решением что слегка устанете 1. находить конфликты без fail. 2 exclude-ить их ручками. Причем, чем больше проект, тем сильнее устанете. Не масштабируемо.
И так, что мы имеем с гуся?
Мы имеем чудесный rule, под обманчивым названием bannedDependencies, которое можно понять как «эти зависимости мы запретим». А вот и нет. Это означает «это запрещенные зависимости, на них мы упадем». «Так это-же твоя любимая стратегия fail!» воскликнут неумные среди нас, и будут не правы. Стратегия fail роняет сборку при наличии конфликта, а enforcer роняет при наличии конкретно прописанной зависимости.
Обратите внимание на использованные библиотеки в примере (он с сайта плагина) — commons-logging, log4j! Они запрещены не из-за конфликтов версий, а из-за конфликтов библиотек! Про мотивацию и исполнение запретов такого вида читать тут (инглиш).
Короче, не то :)
На этот класс нигде в коде больше не ссылаются, так что никаких конфликтов не будет. Зато для ознакомительного материала это очень удобно, можно показать о каком классе фреймворка идёт речь без копания в импортах. Самое гавное — хорошие названия ценны, особенно в таких статьях. Зачем отказываться?