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

Откуда:
Сообщений: 586
Всем привет!

Сделал на Spring Boot 2.1.2 простейшее Web приложение с 1-м @Controller классом и одним @GetMapping("/"), выводящим html страницу.
Размер War файла - 19Мб

Как можно уменьшить размер War файла?
Если сделать на Java EE такое же простейшее приложение, размер будет меньше/больше?

С большими проектами размер war файла не будет расти с арифметической прогрессией?
22 янв 19, 13:59    [21791108]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
сезонатор
Member

Откуда:
Сообщений: 7
Molasar
С большими проектами размер war файла не будет расти с арифметической прогрессией?
Если Вы добавите ещё один контроллер, то размер war-файла не станет равным 38МБ. Вы можете проверить это сами.
22 янв 19, 14:03    [21791118]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 15471
Molasar,

а ты посмотрел, что находится в war?
как минимум библиотеки можно исключить.
но для этого они должны находиться где положено.
Molasar
С большими проектами размер war файла не будет расти с арифметической прогрессией?
как правило либы используются многократно, поэтому прогрессии не будет
22 янв 19, 14:03    [21791119]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38039
Molasar,
Что за вопрос странный. Это zip архив. Что там внутри большое конкретнее)))) LOL
22 янв 19, 14:21    [21791152]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
Petro123
Molasar,
Что за вопрос странный. Это zip архив. Что там внутри большое конкретнее)))) LOL

<artifactId>spring-boot-maven-plugin</artifactId> внутри секции build.
22 янв 19, 14:29    [21791163]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
Molasar
Как можно уменьшить размер War файла?

Использовать exclusions совместно с maven.
22 янв 19, 14:29    [21791164]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 15471
Molasar,

посмотри что находится в .war\WEB-INF\lib\
все либы
"всё своё ношу с собой"
22 янв 19, 14:49    [21791207]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Garrick
Member

Откуда: Москва
Сообщений: 2907
Molasar,

там внутри какой-нибудь сервер, типа Jetty, упакорван.
22 янв 19, 14:54    [21791218]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38039
Вы не даете автору даже посмотреть размеры файлов внутри.
Пусть работает.
22 янв 19, 15:00    [21791227]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Kachalov
Member

Откуда: Москва
Сообщений: 5618
Molasar
Как можно уменьшить размер War файла?
Если сделать на Java EE такое же простейшее приложение, размер будет меньше/больше?


- в порядке развлечения, на днях, делал SpringBoot проект (~50Мб) и аналогичный на JavaEE (~10Мб). Собственно тут все просто - сервер приложений уже содержит все необходимые имплементации JavaEE.

- можно и SpringBoot приложение уменьшить, оно тянет много лишнего. Если проект под maven, то exclusion Вам поможет. Например чтобы не тянуть embedded Tomcat в свое приложение и т п.
22 янв 19, 15:47    [21791294]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
mayton
Member

Откуда: loopback
Сообщений: 39933
Molasar
Всем привет!

Сделал на Spring Boot 2.1.2 простейшее Web приложение с 1-м @Controller классом и одним @GetMapping("/"), выводящим html страницу.
Размер War файла - 19Мб

Как можно уменьшить размер War файла?
Если сделать на Java EE такое же простейшее приложение, размер будет меньше/больше?

С большими проектами размер war файла не будет расти с арифметической прогрессией?

19 mb это очень мало для современного энтерпрайза.

А какой у тебя сборщик? mvn? gradle?
22 янв 19, 16:11    [21791317]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Sergunka
Member

Откуда:
Сообщений: 1748
Garrick
Molasar,

там внутри какой-нибудь сервер, типа Jetty, упакорван.


Jetty надо спецом покавать, там по умолчанию Томкет.
22 янв 19, 19:23    [21791501]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Sergunka
Member

Откуда:
Сообщений: 1748
mayton
Molasar
Всем привет!

Сделал на Spring Boot 2.1.2 простейшее Web приложение с 1-м @Controller классом и одним @GetMapping("/"), выводящим html страницу.
Размер War файла - 19Мб

Как можно уменьшить размер War файла?
Если сделать на Java EE такое же простейшее приложение, размер будет меньше/больше?

С большими проектами размер war файла не будет расти с арифметической прогрессией?

19 mb это очень мало для современного энтерпрайза.

А какой у тебя сборщик? mvn? gradle?


У нас в облаке под развертку просит 380МБ если надо тысячу нодов загрузить довольно накладно - приходится на Го переписывать только из-за памяти.

Видимо ТС требуется так и не доучив яву начать учить Го
22 янв 19, 19:26    [21791506]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
mayton
Member

Откуда: loopback
Сообщений: 39933
На AWS lambda есть ограничения в 128 Мь на артифакт.

Кстати половина проблем фиксятся если внимательно смотреть mvn dependency:tree. Что включается?
Почему? Какие зависимости тянутся? Нужны они или нет?

Я как-то затянул aws-sdk хотя мне надо было отдельно взять aws-s3, aws-lambda e.t.c. Вобще внимательно
смотрите что включается.

Для gradle тоже есть плагин зависимостей. Ну... был вроде.
22 янв 19, 19:37    [21791517]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 15471
один и тот же проект собранный ant - 35м , maven - 65м
22 янв 19, 19:54    [21791529]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
mayton
Member

Откуда: loopback
Сообщений: 39933
А чем отличается состав артефактов?
22 янв 19, 23:12    [21791648]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 15471
mayton,

был проект созданный в NB "стандартным способом" сборки ant
потом просто преобразован в в сборку maven
разница в составе папки lib.
23 янв 19, 07:04    [21791729]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3183
mayton
А чем отличается состав артефактов?
Отличается скорее всего выкидыванием NCDF и CNF
23 янв 19, 07:42    [21791739]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5055
Molasar, а можно pom файл(в очередной раз - вопрос без pom файла не имеет смысла)?
23 янв 19, 08:13    [21791745]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5055
вадя
mayton,

был проект созданный в NB "стандартным способом" сборки ant
потом просто преобразован в в сборку maven
разница в составе папки lib.


хотел бы я глянуть на это "преобразование".
23 янв 19, 08:17    [21791747]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 15471
Озверин
хотел бы я глянуть на это "преобразование".
создан проект maven и просто скопированы все файлы из проекта ant в среде NB.
ну и исправлены ошибки в pom по мере возникающие в процессе компиляции.
коды проекта без изменения
23 янв 19, 09:31    [21791784]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
SQL2008
Member

Откуда:
Сообщений: 3724
сезонатор
Molasar
С большими проектами размер war файла не будет расти с арифметической прогрессией?
Если Вы добавите ещё один контроллер, то размер war-файла не станет равным 38МБ. Вы можете проверить это сами.

Возьмусь написать контроллер размером 19 мб!
Оплата сдельная - 1 мб = 10 к.руб :)
23 янв 19, 09:47    [21791799]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
mayton
Member

Откуда: loopback
Сообщений: 39933
вадя
Озверин
хотел бы я глянуть на это "преобразование".
создан проект maven и просто скопированы все файлы из проекта ant в среде NB.
ну и исправлены ошибки в pom по мере возникающие в процессе компиляции.
коды проекта без изменения

Ты когда нибудь запускал своё приложение с ключиком verbose:class ?
23 янв 19, 10:18    [21791822]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 15471
mayton
Ты когда нибудь запускал своё приложение с ключиком verbose:class ?
нет
а смысл?
мне нужен war для деплоя в линуксах
23 янв 19, 10:21    [21791827]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5055
вадя
mayton
Ты когда нибудь запускал своё приложение с ключиком verbose:class ?
нет
а смысл?
мне нужен war для деплоя в линуксах


может это Алиса?
23 янв 19, 10:53    [21791871]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 15471
Озверин
может это Алиса?
???
23 янв 19, 11:04    [21791889]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
mayton
Member

Откуда: loopback
Сообщений: 39933
вадя
mayton
Ты когда нибудь запускал своё приложение с ключиком verbose:class ?
нет
а смысл?
мне нужен war для деплоя в линуксах

War содержит jar-ники (обычно) и твои собственные .class files.
Если jar-ники распаковать и посмотреть - там будет много шлака.
Из того что в твоём коде может и не используется. Но входит
в артифакт просто потому что владелец этого артифакта так захотел.

Можно зачистить jar-ники удалив ненужное и тогда счастливый Molasar
получит вместо 10М вместо 19 а то и того меньше.
23 янв 19, 11:28    [21791926]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38039
mayton,
Не дело прикладного прогера этим заниматься... Если либы из внешнего репо.
23 янв 19, 11:52    [21791954]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
mayton
Member

Откуда: loopback
Сообщений: 39933
Как будет угодно.

Впрочем... глубину участия в разработке других либ каждый сам для себя определяет самостоятельно.
Мои коллеги коммитили в Camel, Hibernate репки. Тоесть... как-бы проявляли большее участие
в life-cycle смежных фреймворков и библиотек.
23 янв 19, 11:55    [21791955]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 15471
mayton
Если jar-ники распаковать и посмотреть - там будет много шлака.
Из того что в твоём коде может и не используется. Но входит
в артифакт просто потому что владелец этого артифакта так захотел.
куча лишнего в наборе библиотек
в NB в папке Dependencies ручками Exclude Dependency методом проб и ошибок исключил лишнее
war стал 26 мег


Andy_OLAP
Использовать exclusions совместно с maven.

прав
но как это автоматизировать?
23 янв 19, 12:01    [21791961]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
mayton
Member

Откуда: loopback
Сообщений: 39933
Есть dependency явные. Это зависимости меж-библиотек и то что прописано в imports.

Есть зависимости которые появляются в рантайме. Это к примеру jdbc дрова. Плагины.
И протрекать последние - сложно. Нужно прогнать все кейcы приложения.
Я поэтому и писал про verbose:class.
23 янв 19, 12:35    [21791977]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 15471
mayton
Есть зависимости которые появляются в рантайме. Это к примеру jdbc дрова. Плагины.
И протрекать последние - сложно. Нужно прогнать все кейcы приложения.
Я поэтому и писал про verbose:class.
ну NB контролирует зависимости и импорты.
видимо maven перестраховывается и добавляет всё...
23 янв 19, 12:44    [21791982]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
mayton
Member

Откуда: loopback
Сообщений: 39933
Как он это контролирует?
23 янв 19, 12:48    [21791988]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 15471
mayton
Как он это контролирует?
видимо проверяет цепочки вызовов
пока не добавишь jar-либу будет показывать ошибку.
23 янв 19, 12:53    [21791998]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
mayton
Member

Откуда: loopback
Сообщений: 39933
Мы-же говорим про фазу runtime?
23 янв 19, 12:56    [21792001]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 15471
mayton
Мы-же говорим про фазу runtime?
NB это контролирует на фазе написания кода, и пока проблем с эти в фазе рантайма не было.
23 янв 19, 13:04    [21792019]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
mayton
Member

Откуда: loopback
Сообщений: 39933
Да по фазе написания у меня нет вопросов.
23 янв 19, 13:30    [21792053]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 15471
mayton
Да по фазе написания у меня нет вопросов.
тогда я не понял.....
23 янв 19, 13:38    [21792069]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
alex55555
Member

Откуда:
Сообщений: 1976
Sergunka
У нас в облаке под развертку просит 380МБ если надо тысячу нодов загрузить довольно накладно - приходится на Го переписывать только из-за памяти.

Ну вот, логичный результат поигрушек в программистов. Сначала накуролесили на 380 мб непойми чего (большая часть абсолютно не нужна), а потом из-за надоевшего собственного сэкспериментирования решили заняться "сексом по новому". Ну так в новом сексе опять миллион ненужных запчастей будет, проблема очень быстро повторится.
23 янв 19, 14:44    [21792214]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
mayton
Member

Откуда: loopback
Сообщений: 39933
alex55555
Sergunka
У нас в облаке под развертку просит 380МБ если надо тысячу нодов загрузить довольно накладно - приходится на Го переписывать только из-за памяти.

Ну вот, логичный результат поигрушек в программистов. Сначала накуролесили на 380 мб непойми чего (большая часть абсолютно не нужна), а потом из-за надоевшего собственного сэкспериментирования решили заняться "сексом по новому". Ну так в новом сексе опять миллион ненужных запчастей будет, проблема очень быстро повторится.

Я согласен с сарказмом. Но корень этой проблемы растет из неограниченности размера war/jar артифакта.
И кстати он не связан 1:1 с потребляемой памятью.
23 янв 19, 14:48    [21792224]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 9080
mayton
Но корень этой проблемы растет из неограниченности размера war/jar артифакта
Вы путаете причину и следствие.
Причина - неуправляемые (по факту) зависимости.
Следствие - точно такой же рост размера артефактов.
23 янв 19, 15:11    [21792283]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 15471
Basil A. Sidorov
Причина - неуправляемые (по факту) зависимости.
Следствие - точно такой же рост размера артефактов
+100
как избежать этого?
23 янв 19, 15:41    [21792338]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
mayton
Member

Откуда: loopback
Сообщений: 39933
Артефакт org.hibernate:hibernate-core:5.4.1.Final имеет зависимости описанные здесь.

http://central.maven.org/maven2/org/hibernate/hibernate-core/5.4.1.Final/hibernate-core-5.4.1.Final.pom

Их описал человек. Что здесь - неуправляемое?
23 янв 19, 15:48    [21792351]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 9080
mayton
Их описал человек. Что здесь - неуправляемое?
Человеческий фактор.
Вы делегировали "кому-то другому" работу, которую должны делать вы. Ну или кто-то из вашей команды.
Да, взамен вы получили разные плюшки вида "об этом не надо думать" и "оно всё само", но важно понимать, чем именно вы заплатите за эту "лёгкость".
23 янв 19, 15:55    [21792354]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5055
Basil A. Sidorov
mayton
Их описал человек. Что здесь - неуправляемое?
Человеческий фактор.
Вы делегировали "кому-то другому" работу, которую должны делать вы. Ну или кто-то из вашей команды.
Да, взамен вы получили разные плюшки вида "об этом не надо думать" и "оно всё само", но важно понимать, чем именно вы заплатите за эту "лёгкость".


dependencyManagement 


Вроде как работает более или менее.
23 янв 19, 16:00    [21792361]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
mayton
Member

Откуда: loopback
Сообщений: 39933
Basil A. Sidorov
mayton
Их описал человек. Что здесь - неуправляемое?
Человеческий фактор.
Вы делегировали "кому-то другому" работу, которую должны делать вы. Ну или кто-то из вашей команды.
Да, взамен вы получили разные плюшки вида "об этом не надо думать" и "оно всё само", но важно понимать, чем именно вы заплатите за эту "лёгкость".

Чем это отличается от других языков и технологий? Создатель hibernate-core решил что эти зависимости ему нужны.
Имеет право. В других ЯП и технологиях (С++) если не было мейк-файла - вы читаете нудный документ
типа гайда по установке и использованию и качаете библиотеки. Ставите их куда надо и конфигурите
линкер чтоб он их увидел.

Это называется управление зависимостями.
23 янв 19, 16:01    [21792364]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 9080
Озверин
Вроде как работает более или менее.
Ровно в одном сценарии - опишем всё, что может понадобиться.
Это, условно говоря, принцип "гарантированной достаточности".
А минимизация размера это, условно говоря, принцип "абсолютного минимализма".
Разные критерии - разные результаты.
23 янв 19, 16:08    [21792378]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38039
mayton
Это называется управление зависимостями.
это ручной режим.
Бери шарп. Там автомат)))
23 янв 19, 16:12    [21792381]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 9080
mayton
Создатель hibernate-core решил что эти зависимости ему нужны.
"Я подчеркнул".
Имеет право.
А правах его никто и не ограничивает.
В других ЯП и технологиях (С++) если не было мейк-файла - вы читаете нудный документ
типа гайда по установке и использованию и качаете библиотеки.
Ставите их куда надо и конфигурите линкер чтоб он их увидел.

Это называется управление зависимостями.
"Это" называется "управление сборкой".
И, опять-таки, оптимизируется ровно одна задача - быстрая сборка на системе разработчика.
И, опять-таки, "не очень хорошо" подходит для сборки у конечных пользователей.

P.S.
Не очень корректно переносить процесс сборки исполняемого файла на систему с полностью динамической компоновкой.
23 янв 19, 16:15    [21792389]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
mayton
Member

Откуда: loopback
Сообщений: 39933
Об чем здесь идет спор? Кто хочет зависимости подключать "по другому"?

Может быть у вас есть какая-то идея? Ну расскажите?
23 янв 19, 16:21    [21792399]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 9080
mayton
Ну расскажите?
"Вам не понравится".
А во-вторых - "это экономически неэффективно".
23 янв 19, 16:26    [21792407]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38039
Коротко суть спора - за все приходится платить:)
23 янв 19, 16:27    [21792408]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Озверин
Member

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


мы давно перешли от водопада к итерациям - итеративно разбираться, что грузится, что надо и что описываем. Процесс постоянный.
23 янв 19, 16:27    [21792413]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3183
mayton
Артефакт org.hibernate:hibernate-core:5.4.1.Final имеет зависимости описанные здесь.

http://central.maven.org/maven2/org/hibernate/hibernate-core/5.4.1.Final/hibernate-core-5.4.1.Final.pom

Их описал человек. Что здесь - неуправляемое?
Ну проблема примерно такого плана: они логируют все через jboss-logging, если отвлечься от того что, что jboss колхозники и ставят зависимости почему-то provided вместо optional, то получается так, что при деплое поделки в jboss будут возникать пляски с настройкой логирования, если приложение логирует не через jboss-logging - команде хибера нужно было делать shade для этого jboss-logging, а не как прямую зависимость включать. С javassist там тоже проблемы.
23 янв 19, 16:30    [21792420]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
mayton
Member

Откуда: loopback
Сообщений: 39933
Petro123
Коротко суть спора - за все приходится платить:)

Я надеюсь что эволюция здесь работает как главный фактор
того какие и как инструменты мы используем и будем
использовать в будущем.
23 янв 19, 16:31    [21792423]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3183
Озверин
dependencyManagement 


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

<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <version>${fasterxml.version}</version>
</dependency>


и после этого быть уверенным, что он затащит jackson-core и jackson-annotations той же версии - любая зависимость, в которой jackson-core будет явно указан затащит свою версию, в итоге приходится для каждого jar указывать версию - ад и израиль.
23 янв 19, 16:48    [21792448]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5055
Андрей Панфилов, да, именно поэтому - процесс итеративный, но вполне решаемый, причем за достаточно короткий промежуток времени. Но - это все таки процесс, а не "раз и готово".
23 янв 19, 16:57    [21792459]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
mayton
Member

Откуда: loopback
Сообщений: 39933
До модулей дойдем?
23 янв 19, 16:57    [21792461]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38039
mayton
Petro123
Коротко суть спора - за все приходится платить:)

Я надеюсь что эволюция здесь работает как главный фактор
того какие и как инструменты мы используем и будем
использовать в будущем.
мы уже платим. Сегодня.
Мне пофиг на размер, если я гружу библиотеку с репо.
Вадя перфекционист и ему нужно размер и скорость.
Плохо что грань поиска килобайт нигде не обучают.
Иногда нужно забить на размер.
23 янв 19, 17:05    [21792470]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
mayton
Member

Откуда: loopback
Сообщений: 39933
Не Вадя. Другой мембер вопрос поднял. У меня тоже был вопрос толстых сборок под AWS-Lambda
но он пофиксился просто наблюдением над dependency:tree.

Лишним перфексионизмом я тоже не страдаю. Просто надо было добить артифакт хотя-бы до 128Мб
23 янв 19, 17:07    [21792475]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 15471
Petro123
Мне пофиг на размер, если я гружу библиотеку с репо.
Вадя перфекционист и ему нужно размер и скорость.
Плохо что грань поиска килобайт нигде не обучают.
Иногда нужно забить на размер.
и согласен и нет
по большому счёту размер по-фигу. с другой стороны время сборки war удручает. и при деплое на клиента, если клиент тесовая машина не понятно где, и инет ограничен - то ж не радует...
по мелочам , а набегает - вот это огорчает
23 янв 19, 17:11    [21792479]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
mayton
Member

Откуда: loopback
Сообщений: 39933
вадя
Petro123
Мне пофиг на размер, если я гружу библиотеку с репо.
Вадя перфекционист и ему нужно размер и скорость.
Плохо что грань поиска килобайт нигде не обучают.
Иногда нужно забить на размер.
и согласен и нет
по большому счёту размер по-фигу. с другой стороны время сборки war удручает. и при деплое на клиента, если клиент тесовая машина не понятно где, и инет ограничен - то ж не радует...
по мелочам , а набегает - вот это огорчает

После перехода на gradle время субъективно улучшается в пару раз.
В основном за счет 4х рабочих java-процессов сборщиков которые
постоянно подняты в памяти и ждут заданий. В отличие от mvn
который стартует медленнее.
23 янв 19, 17:18    [21792490]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3183
Озверин
Андрей Панфилов, да, именно поэтому - процесс итеративный, но вполне решаемый, причем за достаточно короткий промежуток времени. Но - это все таки процесс, а не "раз и готово".
Решаемо - это как у Вади? на ant перейти? Не хочу чтобы итеративно было, хочу чтобы оно работало более очевидно чем сейчас, т.е.: если я в dependencyManagement указал артефакт с определенной версией, то оно и для всех его зависимостей должно версии зафиксировать, а не так как сейчас - кто ближе тот и прав, ну и еще можно хотелок накидать в духе глобальных exclude, или описания того какой API/JSR реализует тот или иной артефакт, чтобы нельзя было два одновременно сложить вместе, или отделения test-зависимостей от compile.
23 янв 19, 17:18    [21792494]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38039
вадя
время сборки war
да брось. Сколько?
23 янв 19, 17:19    [21792495]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 15471
Petro123
вадя
время сборки war
да брось. Сколько?
3 сек и 15 сек
на сборку.
мелочь . но раздражает. особенно когда что-то не получается и нужно ждать...
23 янв 19, 17:26    [21792514]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
mayton
Member

Откуда: loopback
Сообщений: 39933
По 15 минут собирали.
23 янв 19, 17:28    [21792516]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Озверин
Member

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


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

<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <version>${fasterxml.version}</version>
</dependency>


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


в итоге приходится - исключать ненужные после конфликт резолвинга. Я не очень понимаю, как вы собираетесь автоматизировать эту проблему.
23 янв 19, 17:29    [21792518]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3183
Озверин
в итоге приходится - исключать ненужные после конфликт резолвинга. Я не очень понимаю, как вы собираетесь автоматизировать эту проблему.
В gradle к примеру, подобных проблем нет (ну или по крайней мере они сведены к минимуму), ну и остальных приколов тоже поменьше будет (например, то что предоставляет сервер приложений можно просто описать как новую конфигурацию, а потом вычесть одну и другой)
23 янв 19, 17:39    [21792536]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38039
mayton
По 15 минут собирали.
ну дак у вас большие проекты.
Странно когда новичек вставивший контроллер беспокоится)
23 янв 19, 17:45    [21792539]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Озверин
Member

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


но вместе с dependencyManagment стратегия разрешения конфликтов становится очевидной. Мавен - менее гибок, но вполне очевиден, если требуется. То есть, если в dependencyManagment указана конкретная версия и среди конфликтов эта версия есть - используется она, другой вопрос, что версия может быть указана, но среди всех заивисимостей ее нет - тогда тут уже вступает в силу закон, кто ближе к корню.
23 янв 19, 18:42    [21792588]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
mayton
Member

Откуда: loopback
Сообщений: 39933
Суровые конфликты идут обычно когда вливаются 2 разные версии одного и того-же продукта.
Помню часто gclib требовался в проекте в двух вариантах. Причем младшая версия тоже была
нужна.

Фиксили это заворачивая модуль в OSGI-bundle. (Это еще до девятки). Бандлы вобщем-то решали
свою задачу но практически в разработке их программеры люто ненавидели. За многословность.
Громоздкость и практически невостребованность со стороны кастомера.

С модулями девятки я еще не работал - поэтому практически не знаю как оно там "внутре".

Вобщем... тема для пятницы.
23 янв 19, 19:55    [21792626]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
alex55555
Member

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

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

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

Привычка делать всё "по быстрому" и "не парясь" до добра никогда не доводила.
24 янв 19, 14:47    [21793405]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Озверин
Member

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

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

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

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


сижу, записываю новую для себя информацию.
24 янв 19, 14:49    [21793410]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 15471
alex55555
Идея простая - проектировать.
ну в общем я так и поступаю - с проектирования...
но вот по теме топика как-то не получается
т.е. надо решить maven vc ant?
24 янв 19, 15:12    [21793459]     Ответить | Цитировать Сообщить модератору
 Re: Большой размер war файлов  [new]
Озверин
Member

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


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

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

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