|
Большой размер war файлов
|
|||
---|---|---|---|
#18+
Чото взоржал. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2019, 15:31 |
|
Большой размер war файлов
|
|||
---|---|---|---|
#18+
Озверинant работает с зависимостями?нет. он просто подтягивает библиотеки которые ему укажешь. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2019, 15:34 |
|
Большой размер war файлов
|
|||
---|---|---|---|
#18+
вадяОзверинant работает с зависимостями?нет. он просто подтягивает библиотеки которые ему укажешь. допустим, что он даже мавен не юзает(хотя кодга я в последний раз работал с этим древним отложением мамонта, он юзал мавен таски , потому что никакого собственного депенденси менеджмента у него отродясь не было), если у него нет инструментов вменяемых для работы с зависимостиям - то какие тут могут быть или? Тогда уж gradle. Или ant в связки с чем-нибудь, что умеет в менеджмент зависимостей. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2019, 15:36 |
|
Большой размер war файлов
|
|||
---|---|---|---|
#18+
alex55555maytonМожет быть у вас есть какая-то идея? Ну расскажите? Идея простая - проектировать. Ну а реализация сложная. Но для начала нужно выполнять хотя бы минимальные требования, давно известные всем. Например - всё должно быть простым. Это отнюдь не с потолка взявшееся правило. Но такое важное ограничение практически очень часто не соблюдается. Берут одну систему, к ней прикручивают другую, потом третью и в итоге получается адская смесь из всего на свете, которая работает только тогда, когда сама этого захочет. А вот если бы с самого начала думали о последствиях, продумывали бы вопросы сложности, совместимости, масштабирования, расширения и т.д., тогда бы массы проблем просто не возникло бы. Но хочется же сделать быстрее, плюс бизнес сроки зажимает. Вот и берут что есть, втыкают лишь бы заработало, а потом удивляются - ну почему вдруг у нас прожект так разросся? И управление зависимостями в мавене и прочем сильно далеко от идеала, но опять же - раз оно там есть, то по быстрому прикрутили и нарисовали в бложеке "сакцесс стори", ура-ура, мы победили. Только сложность-то осталась, победа локальная, а в целом ситуация только ухудшилась. Привычка делать всё "по быстрому" и "не парясь" до добра никогда не доводила. Эволюционный путь - предполагает скорость реализации. Если есть две команды. И одна из них выдает решение быстрее - то она всегда будет получать заказы на новые проекты. Риски сюда тоже заложены. Ведь первая команда их и будет решать. Вторая команда фейлит сроки. Фейлит один раз. Второй. А потом она вообще не участник разработки. Заказов нет. Эволюционный путь. Философские рассуждения о том что надо проектировать я 100% принимаю и соглашаюсь. Думания о последствиях также важны. Но сколько времени вы будете думать? День? Неделю? Месяц? Когда у вас будет definition of done? Вот в чем вопрос. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2019, 15:55 |
|
Большой размер war файлов
|
|||
---|---|---|---|
#18+
Озверинant работает с зависимостями? Легко! Только самому всё прописать надо ручками :) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2019, 16:10 |
|
Большой размер war файлов
|
|||
---|---|---|---|
#18+
GarrickЛегко! Только самому всё прописать надо ручками :)дак и в maven , если прописать ручками, можно сократить..... ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2019, 16:51 |
|
Большой размер war файлов
|
|||
---|---|---|---|
#18+
maytonalex55555пропущено... Идея простая - проектировать. Ну а реализация сложная. Но для начала нужно выполнять хотя бы минимальные требования, давно известные всем. Например - всё должно быть простым. Это отнюдь не с потолка взявшееся правило. Но такое важное ограничение практически очень часто не соблюдается. Берут одну систему, к ней прикручивают другую, потом третью и в итоге получается адская смесь из всего на свете, которая работает только тогда, когда сама этого захочет. А вот если бы с самого начала думали о последствиях, продумывали бы вопросы сложности, совместимости, масштабирования, расширения и т.д., тогда бы массы проблем просто не возникло бы. Но хочется же сделать быстрее, плюс бизнес сроки зажимает. Вот и берут что есть, втыкают лишь бы заработало, а потом удивляются - ну почему вдруг у нас прожект так разросся? И управление зависимостями в мавене и прочем сильно далеко от идеала, но опять же - раз оно там есть, то по быстрому прикрутили и нарисовали в бложеке "сакцесс стори", ура-ура, мы победили. Только сложность-то осталась, победа локальная, а в целом ситуация только ухудшилась. Привычка делать всё "по быстрому" и "не парясь" до добра никогда не доводила. Эволюционный путь - предполагает скорость реализации. Если есть две команды. И одна из них выдает решение быстрее - то она всегда будет получать заказы на новые проекты. Риски сюда тоже заложены. Ведь первая команда их и будет решать. Вторая команда фейлит сроки. Фейлит один раз. Второй. А потом она вообще не участник разработки. Заказов нет. Эволюционный путь. Философские рассуждения о том что надо проектировать я 100% принимаю и соглашаюсь. Думания о последствиях также важны. Но сколько времени вы будете думать? День? Неделю? Месяц? Когда у вас будет definition of done? Вот в чем вопрос.Диалоги демагогов ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2019, 17:28 |
|
Большой размер war файлов
|
|||
---|---|---|---|
#18+
Андрей ПанфиловОзверинant работает с зависимостями? внезапно Совершенно не внезапно, потому что это Maven, точнее его часть - Maven Ant Tasks, которая генерит данные для Ant. Maven Ant Tasks Note: This component is retired. It is no longer maintained ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2019, 23:05 |
|
Большой размер war файлов
|
|||
---|---|---|---|
#18+
вадят.е. надо решить maven vc ant? Вообще лучше постепенно вырабатывать не усложняющий жизнь набор инструментов. А уж что там для сборки прикрутить - дело десятое. По зависимостям ещё OSGi работает. Ну и вообще граф зависимостей и операции с ним отнюдь не рокет сайнс, так что можно и самому небольшую утилитку слепить. Только ещё до зависимостей нужно уметь хотя бы элементарно выделять общие библиотеки и ложить их в общий для всего сервера каталог, а не пихать в каждое приложение, а то-ж в приложение напихают всего, потом так же в другое, потом в третье, и никто ничего не согласовывает, ну и лезут конфликты, я уж не говорю про объём. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2019, 15:59 |
|
Большой размер war файлов
|
|||
---|---|---|---|
#18+
maytonЭволюционный путь - предполагает скорость реализации. Бизнесу важна цена. Скорость для них второстепенна. А вот убеждение заказчика в выполнении задачи в некий срок ХХХ, а потом срыв этого срока, это уже работа сейлзов, а не программистов. Хотя и программисты могут лишку оптимистичные заявки выкладывать, да. Но с другой стороны, наш бизнес живёт сегодняшним днём, завтрашний день его будет волновать когда он наступит, поэтому опять возникает стимул продать сроки, то есть ублажить хотелку сейчас, а дальше - что будет то и будет, главное бабло срубили. В общем опять программисты не виноваты. Но всё же помнить об этом нужно. И уметь делать надолго - тоже нужно. Хотя тренироваться в современном ынтырпрайзе на эту тему весьма и весьма сложно. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2019, 16:05 |
|
Большой размер war файлов
|
|||
---|---|---|---|
#18+
Беря во внимание вопрос топик-стартера мне нечего добавить или возразить. Все - верно. Но неверно будет впадать в каменный век и собирать сборки через java + jar archiver. Для мелкого проекта как у автора на это можно пойти. Но в ентерпрайзе этому места нет. Хотя еще раз я согласен с ценой разработки и скоростью. Надеюсь что на двумерной диаграмме будет совершенно очевидна заинтересованность заказчика в скорости внедрения бизнес-фичи и в качестве написанного кода. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2019, 19:15 |
|
Большой размер war файлов
|
|||
---|---|---|---|
#18+
alex55555Только ещё до зависимостей нужно уметь хотя бы элементарно выделять общие библиотеки и ложить их в общий для всего сервера каталог, а не пихать в каждое приложение, а то-ж в приложение напихают всего, потом так же в другое, потом в третье, и никто ничего не согласовывает, ну и лезут конфликты, я уж не говорю про объём.напихать все в одно приложение(war) в этом есть смысл: разворачиваешь сервер( к примеру что-то из никсов) и просто деплоишь туда вар. надо переустановить сервер/ развернуть новый - не надо вспоминать , что там было - просто деплоишь и всё работает... ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2019, 19:41 |
|
Большой размер war файлов
|
|||
---|---|---|---|
#18+
ОзверинМавен - менее гибок, но вполне очевиден, если требуетсяОзверинкодга я в последний раз работал с этим древним отложением мамонтаКак-то у меня отношение ко всему этому хламу несколько иное, тезисы примерно такие: в свое время SUN придумал ant как замену make (при этом make живее всех живых ), позже передал его в ASF, а эти колхозники его взяли и убили (ну вообще такова репутация ASF - могила open source), а на замену выкатили какую-то фигню, которая ни зависимости не умеет толком (в моем идеализированно представлении) ни сборку сделать "условно сложный" (пара десятков модулей, интеграционные тесты, сборки под разные сервера приложений) проект на maven можно, но крайне сложно, основная причина тому: отсутствие зависимостей между модулями проекта, со всеми вытекающими, т.е.: -- "однопроходную" сборку делать априори плохо, потому что в "условно сложном" проекте участвуют разные команды, поэтому они предпочитают что-то собирать частями просто потому что так быстрее получается, делать отдельные "дыры" в сборке при помощи профилей - идея на самом деле так себе: во-первых, это сложно рефакторить, потому что подобный рефакторинг затрагивает остальных членов команды, во-вторых, сложность проекта увеличивается в разы, а когда мы всю эту кашу пытаемся затащить в CI, то становится еще более печально - появляются разные бранчи и пр. -- когда мы отказывается от "однопроходной" сборки, начинаются проблемы с тем, что чтобы удовлетворить зависимости между модулями нужно уже гадить в ~/.m2, и тут приходится выдумывать какую-то необычайную фигню - например, в CI использовать docker, что в свою очередь уже добавляет проблем разработчикам -- писать плагины для maven в том же проекте не получается, потому что у него там какое-то собственное мнение про класлоадер и в общем получается так, что maven - это удел проектов с не более пяти модулями, без интеграционных тестов и с убогой инфраструктурой. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2019, 10:27 |
|
|
start [/forum/topic.php?fid=59&startmsg=39764416&tid=2121519]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
72ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
54ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 186ms |
0 / 0 |