Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Java Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4]      все
 Re: Большой размер war файлов  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3184
Озверин
ant работает с зависимостями?


внезапно
24 янв 19, 15:24    [21793494]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5055
Андрей Панфилов
Озверин
ant работает с зависимостями?


внезапно


такси дла мавена шоле?:)
24 янв 19, 15:30    [21793509]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5055
Чото взоржал.
24 янв 19, 15:31    [21793512]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 15471
Озверин
ant работает с зависимостями?
нет.
он просто подтягивает библиотеки которые ему укажешь.
24 янв 19, 15:34    [21793516]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5055
вадя
Озверин
ant работает с зависимостями?
нет.
он просто подтягивает библиотеки которые ему укажешь.


допустим, что он даже мавен не юзает(хотя кодга я в последний раз работал с этим древним отложением мамонта, он юзал мавен таски , потому что никакого собственного депенденси менеджмента у него отродясь не было), если у него нет инструментов вменяемых для работы с зависимостиям - то какие тут могут быть или? Тогда уж gradle. Или ant в связки с чем-нибудь, что умеет в менеджмент зависимостей.
24 янв 19, 15:36    [21793521]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
mayton
Member

Откуда: loopback
Сообщений: 39940
alex55555
mayton
Может быть у вас есть какая-то идея? Ну расскажите?

Идея простая - проектировать.

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

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

Эволюционный путь - предполагает скорость реализации.
Если есть две команды. И одна из них выдает решение быстрее - то она всегда будет получать заказы на новые
проекты. Риски сюда тоже заложены. Ведь первая команда их и будет решать. Вторая команда фейлит сроки.
Фейлит один раз. Второй. А потом она вообще не участник разработки. Заказов нет.

Эволюционный путь.

Философские рассуждения о том что надо проектировать я 100% принимаю и соглашаюсь.
Думания о последствиях также важны. Но сколько времени вы будете думать? День? Неделю?
Месяц? Когда у вас будет definition of done?

Вот в чем вопрос.
24 янв 19, 15:55    [21793554]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Garrick
Member

Откуда: Москва
Сообщений: 2907
Озверин
ant работает с зависимостями?

Легко! Только самому всё прописать надо ручками :)
24 янв 19, 16:10    [21793578]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 15471
Garrick
Легко! Только самому всё прописать надо ручками :)
дак и в maven , если прописать ручками, можно сократить.....
24 янв 19, 16:51    [21793633]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
сезонатор
Member

Откуда:
Сообщений: 7
mayton
alex55555
пропущено...

Идея простая - проектировать.

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

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

Эволюционный путь - предполагает скорость реализации.
Если есть две команды. И одна из них выдает решение быстрее - то она всегда будет получать заказы на новые
проекты. Риски сюда тоже заложены. Ведь первая команда их и будет решать. Вторая команда фейлит сроки.
Фейлит один раз. Второй. А потом она вообще не участник разработки. Заказов нет.

Эволюционный путь.

Философские рассуждения о том что надо проектировать я 100% принимаю и соглашаюсь.
Думания о последствиях также важны. Но сколько времени вы будете думать? День? Неделю?
Месяц? Когда у вас будет definition of done?

Вот в чем вопрос.
Диалоги демагогов
Картинка с другого сайта.
24 янв 19, 17:28    [21793678]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Пылинка
Member

Откуда: СПб
Сообщений: 313
Андрей Панфилов
Озверин
ant работает с зависимостями?


внезапно

Совершенно не внезапно, потому что это Maven, точнее его часть - Maven Ant Tasks, которая генерит данные для Ant.

Maven Ant Tasks
Note: This component is retired. It is no longer maintained
24 янв 19, 23:05    [21793847]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
alex55555
Member

Откуда:
Сообщений: 1976
вадя
т.е. надо решить maven vc ant?

Вообще лучше постепенно вырабатывать не усложняющий жизнь набор инструментов. А уж что там для сборки прикрутить - дело десятое. По зависимостям ещё OSGi работает. Ну и вообще граф зависимостей и операции с ним отнюдь не рокет сайнс, так что можно и самому небольшую утилитку слепить. Только ещё до зависимостей нужно уметь хотя бы элементарно выделять общие библиотеки и ложить их в общий для всего сервера каталог, а не пихать в каждое приложение, а то-ж в приложение напихают всего, потом так же в другое, потом в третье, и никто ничего не согласовывает, ну и лезут конфликты, я уж не говорю про объём.
25 янв 19, 15:59    [21794405]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
alex55555
Member

Откуда:
Сообщений: 1976
mayton
Эволюционный путь - предполагает скорость реализации.

Бизнесу важна цена. Скорость для них второстепенна.

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

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

Но всё же помнить об этом нужно. И уметь делать надолго - тоже нужно. Хотя тренироваться в современном ынтырпрайзе на эту тему весьма и весьма сложно.
25 янв 19, 16:05    [21794412]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
mayton
Member

Откуда: loopback
Сообщений: 39940
Беря во внимание вопрос топик-стартера мне нечего добавить или возразить.
Все - верно. Но неверно будет впадать в каменный век и собирать сборки через
java + jar archiver. Для мелкого проекта как у автора на это можно пойти.
Но в ентерпрайзе этому места нет. Хотя еще раз я согласен с ценой разработки
и скоростью. Надеюсь что на двумерной диаграмме будет совершенно очевидна
заинтересованность заказчика в скорости внедрения бизнес-фичи и в качестве
написанного кода.
25 янв 19, 19:15    [21794536]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 15471
alex55555
Только ещё до зависимостей нужно уметь хотя бы элементарно выделять общие библиотеки и ложить их в общий для всего сервера каталог, а не пихать в каждое приложение, а то-ж в приложение напихают всего, потом так же в другое, потом в третье, и никто ничего не согласовывает, ну и лезут конфликты, я уж не говорю про объём.
напихать все в одно приложение(war)
в этом есть смысл: разворачиваешь сервер( к примеру что-то из никсов) и просто деплоишь туда вар. надо переустановить сервер/ развернуть новый - не надо вспоминать , что там было - просто деплоишь и всё работает...
25 янв 19, 19:41    [21794549]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3184
Озверин
Мавен - менее гибок, но вполне очевиден, если требуется
Озверин
кодга я в последний раз работал с этим древним отложением мамонта
Как-то у меня отношение ко всему этому хламу несколько иное, тезисы примерно такие:
  • в свое время SUN придумал ant как замену make (при этом make живее всех живых ), позже передал его в ASF, а эти колхозники его взяли и убили (ну вообще такова репутация ASF - могила open source), а на замену выкатили какую-то фигню, которая ни зависимости не умеет толком (в моем идеализированно представлении) ни сборку
  • сделать "условно сложный" (пара десятков модулей, интеграционные тесты, сборки под разные сервера приложений) проект на maven можно, но крайне сложно, основная причина тому: отсутствие зависимостей между модулями проекта, со всеми вытекающими, т.е.:
    -- "однопроходную" сборку делать априори плохо, потому что в "условно сложном" проекте участвуют разные команды, поэтому они предпочитают что-то собирать частями просто потому что так быстрее получается, делать отдельные "дыры" в сборке при помощи профилей - идея на самом деле так себе: во-первых, это сложно рефакторить, потому что подобный рефакторинг затрагивает остальных членов команды, во-вторых, сложность проекта увеличивается в разы, а когда мы всю эту кашу пытаемся затащить в CI, то становится еще более печально - появляются разные бранчи и пр.
    -- когда мы отказывается от "однопроходной" сборки, начинаются проблемы с тем, что чтобы удовлетворить зависимости между модулями нужно уже гадить в ~/.m2, и тут приходится выдумывать какую-то необычайную фигню - например, в CI использовать docker, что в свою очередь уже добавляет проблем разработчикам
    -- писать плагины для maven в том же проекте не получается, потому что у него там какое-то собственное мнение про класлоадер

    и в общем получается так, что maven - это удел проектов с не более пяти модулями, без интеграционных тестов и с убогой инфраструктурой.
  • 28 янв 19, 10:27    [21795546]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4]      все
    Все форумы / Java Ответить