Basil A. SidorovОзверинВроде как работает более или менее.Ровно в одном сценарии - опишем всё, что может понадобиться.
Это, условно говоря, принцип "гарантированной достаточности".
А минимизация размера это, условно говоря, принцип "абсолютного минимализма".
Разные критерии - разные результаты.

мы давно перешли от водопада к итерациям - итеративно разбираться, что грузится, что надо и что описываем. Процесс постоянный.

Андрей Панфилов, да, именно поэтому - процесс итеративный, но вполне решаемый, причем за достаточно короткий промежуток времени. Но - это все таки процесс, а не "раз и готово".

Андрей ПанфиловОзверин


Вроде как работает более или менее.Вообще не работает, т.е. нельзя просто так взять и написать в dependencyManagement что-то в духе:




и после этого быть уверенным, что он затащит jackson-core и jackson-annotations той же версии - любая зависимость, в которой jackson-core будет явно указан затащит свою версию, в итоге приходится для каждого jar указывать версию - ад и израиль.

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

Андрей ПанфиловОзверинв итоге приходится - исключать ненужные после конфликт резолвинга. Я не очень понимаю, как вы собираетесь автоматизировать эту проблему.В gradle к примеру, подобных проблем нет (ну или по крайней мере они сведены к минимуму), ну и остальных приколов тоже поменьше будет (например, то что предоставляет сервер приложений можно просто описать как новую конфигурацию, а потом вычесть одну и другой)

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

alex55555maytonМожет быть у вас есть какая-то идея? Ну расскажите?
Идея простая - проектировать.

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

Привычка делать всё "по быстрому" и "не парясь" до добра никогда не доводила.

сижу, записываю новую для себя информацию.

вадяalex55555Идея простая - проектировать.ну в общем я так и поступаю - с проектирования...
но вот по теме топика как-то не получается
т.е. надо решить maven vc ant?

ant работает с зависимостями?