Должен ли я быть обеспокоен большим количеством зависимостей?

Question

Я как раз собирался включить библиотеку HtmlUnit в проект.Я распаковал zip-файл и понял, что в нем не менее 12 зависимостей .

Я всегда беспокоился, когда дело доходит до введения зависимостей.Я полагаю, что я должен отправить все эти зависимости вместе с приложением (8,7 МБ в данном конкретном случае).Стоит ли проверять, скажем, обновления безопасности для этих библиотек?Наконец (и самое главное, собственно, то, что меня больше всего беспокоит): Что, если я хочу включить другую библиотеку, которая зависит от тех же библиотек, что и эта библиотека, но с разными версиями?То есть, что, если, например, HtmlUnit зависит от одной версии xalan и другой нужной мне библиотеки, зависит от другой версии xalan?

Задача, которую HtmlUnit решает для меня , может можно решить «вручную», но это, вероятно, будет не так элегантно.

Должен ли я беспокоиться об этом?Каковы лучшие практики в подобных ситуациях?

Редактировать: меня интересует общая ситуация, не особенно связанная с HtmlUnit.Я просто использовал это здесь в качестве примера, так как это было моей текущей заботой.

Answer 1

Обращайтесь с вашими зависимостями осторожно.Они могут принести вам большую скорость, но могут быть трудны для поддержания в будущем.Вот мои мысли:

• Используйте некоторое программное обеспечение для поддержания ваших зависимостей.Maven - это то, что я бы использовал для Java, чтобы сделать это.Без этого вы очень скоро потеряете свои зависимости.
• Помните, что различные библиотеки имеют разные лицензии.Не предоставляется, что данная лицензия работает для вашей настройки.Я работаю в фирме программного обеспечения, и мы не можем использовать библиотеки на основе GPL в любом программном обеспечении, которое мы поставляем, так как мы продаем программное обеспечение с закрытым исходным кодом.Точно так же мы должны избегать LGPL, если сможем (это из-за какой-то сложной аргументации юриста, не спрашивайте меня, почему)
• Для модульного тестирования я бы сказал, изо всех сил.Это не конец света, если вам придется переписать свои тесты в будущем.Может даже случиться так, что эта часть программного обеспечения либо чрезвычайно стабильна, либо, может быть, даже больше не поддерживается.Потерять их не так уж и сложно, поскольку вы уже получили огромный прирост скорости, когда получили их.
• Некоторые библиотеки труднее заменить позже, чем другие.Некоторые из них похожи на брак, который должен длиться жизнь программного обеспечения, но некоторые другие просто инструменты, которые легко заменить.(Подумайте, что Spring против библиотеки xml)
• Узнайте, как сообщество поддерживает более старые версии библиотеки.Они поддерживают старые версии?Что происходит, когда жизнь продолжается, и вы застряли на версии?Есть ли активное сообщество или у вас есть умение поддерживать его самостоятельно?
• Как долго должно продолжаться ваше программное обеспечение?Это один год, пять лет, десять лет или больше?Если у программного обеспечения короткий промежуток времени, то вы можете использовать больше, чтобы добраться туда, куда вы идете, поскольку не так важно иметь возможность идти в ногу с обновлением ваших библиотек.

Answer 2

Это может быть серьезной проблемой, если нет активного сообщества, которое поддерживает библиотеки в долгосрочной перспективе. Можно использовать библиотеки, но, если честно, вам следует позаботиться о том, чтобы получить исходные коды и поместить их в свою VCS.

Answer 3

Стоит ли проверять, скажем, обновления безопасности для этих библиотек?

В общем, это хорошая идея.Но то же самое должны делать все восходящие и нисходящие вас.

В вашем конкретном случае речь идет о тестовом коде.Если потенциальные недостатки безопасности в библиотеках, используемых только в тестировании, значительны, ваши нижестоящие пользователи делают что-то странное ...

Наконец (и, самое главное, на самом деле то, что меня больше всего беспокоит): Что еслиЯ хочу включить другую библиотеку, которая зависит от тех же библиотек, что и эта библиотека, но с разными версиями?То есть, что если, например, HtmlUnit зависит от одной версии xalan и другой библиотеки, которая мне нужна, зависит от другой версии xalan?

Ах, да.Предполагая, что вы создаете собственные пути к классам и т. Д. Вручную, вам необходимо принять решение о том, какую версию зависимых библиотек следует использовать.Обычно безопасно выбрать самую последнюю из использованных версий.Но если старая версия не является обратно несовместимой с новой (для вашего случая использования), то у вас есть проблема.

Должен ли я беспокоиться об этом?

IMO, для вашего конкретного примера (где мы говорим о тестовом коде) нет.

Каковы лучшие практики в подобных ситуациях?

Используйте Maven!Он явно раскрывает зависимости людям, которые скачивают ваш код, что позволяет им решать эту проблему.Он также сообщает вам, когда у вас возникают конфликты версий зависимостей, и предоставляет простой механизм «исключения» для его решения.

Maven также устраняет необходимость создания дистрибутивов.Вы публикуете только своих артефактов с ссылками на их иждивенцев.Затем команда Maven загружает зависимые артефакты оттуда, где они были опубликованы.

EDIT

Очевидно, что если вы используете HtmlUnit для производственного кода (а не просто для тестирования), то вам нужно больше внимания уделять вопросам безопасности.

Answer 4

Я стараюсь избегать несерьезных зависимостей, потому что можно столкнуться с конфликтами.

Одна интересная техника, которую я видел, использовалась, чтобы избежать конфликтов: переименование пакета библиотеки (если ее лицензия позволяет вам - большинство лицензий в стиле BSD.) Мой любимый пример этого - то, что Sun сделала, когда они встроили Xerces в JRE как де-факто анализатор XML JAXP: они переименовали весь Xerces с org.apache.xerces на com.sun.org.apache.xerces.internal. Является ли эта техника радикальной, трудоемкой и трудной в обслуживании? Да. Но он выполняет свою работу, и я думаю, что это важная возможная альтернатива.

Другая возможность - соблюдение условий лицензии - копирование / переименование отдельных классов или даже отдельных методов из библиотеки.

HtmlUnit может сделать много , хотя. Если вы действительно используете большую часть его функциональных возможностей для большого количества разнообразных входных данных, было бы трудно обосновать, что вы потратили бы много времени на переписывание функциональности с нуля или ее переупаковку.

Что касается вопросов безопасности - вы можете взвесить вероятность того, что у широко используемой библиотеки возникнут проблемы, и вероятность того, что у вашего рукописного, менее проверенного кода есть некоторый недостаток безопасности. В конечном счете, вы несете ответственность за безопасность своих программ, поэтому делайте то, что считаете нужным.

Answer 5

Подобное произошло со мной на самом деле.

У двух моих зависимостей была та же самая "транзитивная" зависимость, но другая версия.

Мое любимое решение - избегать "ползучести зависимостей", не включая слишком много зависимостей.Итак, самое простое решение было бы удалить тот, который мне нужен, или тот, который я мог бы заменить простым классом Util и т. Д.

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

В моем конкретном случае я вручную отредактировал одну из флягудалил старую зависимость от нее и надеялся, что она все равно будет работать с новой версией, загруженной из другого jar-файла.К счастью, это произошло (то есть сопровождающие транзитивной зависимости не удалили ни классы, ни методы, которые использовала библиотека).

Это было некрасиво - Да (Тьфу!), Но это сработало.