Рассуждаете так, как будто вам нужно сделать ещё один плагин и надо выбрать способ, который позволит достичь результата с наименьшими трудозатратами.
Нет, я рассуждаю с позиции человека, который прежде чем делать что то новое изучает текущие решения.
То, что он по умолчанию даёт 100% возможностей от оригинала очевидно, но что вы выбрали его именно поэтому - не очевидно. Особенно учитывая, что вы сами озвучили причины по которым вы его выбрали и среди них не было возможностей.
Вам очевидно что он дает 100% возможностей, но вам не очевидно почему я выбрал его, очень странно... особено учитывая что данный плагин появился в 23 году, а ваш только что. Действительно не очевидно.
Есть много людей, которые выбирают софт не потому что в нём есть 100% возможностей, а потому что им нравится как он разрабатывается. Я подумал, что вы один из них.
Ээээ... с чего вы это решили? Я как раз наоборот ценю инженерный подход, мне нравится и то что он закрывает все 100% потребностей, и то что в его основе лежит простая и надежная, как автомат калашников идея и то что он занимает всего 20кб. Зачем мне пробовать какие то альтернативы? Я именно "один из них", кто не любит писать код, ради кода, кто ценит идею - ее простоту и надежность. И для меня самый лучший код тот - который я не написал. И именно поэтому в свое время выстрелили такие плагины как MavenHelper, MavenDependecyHelper, да и "Start Spring Boot Project", потомучто они привнесли что то новое, чего не было в оригинальных плагинах, а не были "такими как все". Именно поэтому они и набрали сотни тысяч и миллионы скачиваний, именно благодаря инженерному подходу и свежему взгляду на проблему и решили проблемы, людей про которых вы сказали "выбирают софт не потому что в нём есть 100% возможностей". Именно это и натолкнуло меня на все написанные мной плагины - что есть "болевые точки" нерешеные проблемы в тех решениях с которыми я работал.
А я как раз хотел спросить про Init Spring. Чего там не хватает? Какие ваши проблемы он не решает? Почему вы выбираете start-spring-boot, а не его?
Потомучто он появился в 23 году, и закрывает все мои потребности и содержит всего 5 классов и он прост и надежен. И с ним не будет такого что при очередном обновлении IDEA или SpringBoot Rest API он превратится в тыкуву. Точнее это конечно может быть, но вероятности намного меньше чем у вашего решения и я перечислил в пером сообщении все потенциальные точки отказа. Зачем мне пробовать что то новое - особенно если очевидно, что оно не дает ничего нового.
Ну как, получается, что про удобство использования я больше аргументов привёл, чем вы.
Мы точно ходим по кругу. Я увидел только один аргумент - про валидацию артефактИд. А удобно/неудобно это ваше субъективное ощущение. Я вам перечислил 5 минусов данного решения. Или оспорте их или приведите вашу аргументы почему ваш плагин лучше, также по пунктам, как это сделал я. А то в больших абзацах текста что вы пишите я не мог ничего разглядеть кроме того что вам лично удобно, Мне удобен - start-spring-boot. И у вас в маркетплейсе нет даже ссылки на исходный код вашего решения.
Или чего вам там не хватает. Напишите, пожалуйста, это интересно
Опять 25. Мне всего хаватает в "start-spring-boot". Потому что это на 100% оригинал и в будущем его не надо будед дорабатывать под новоые возможности, если они появтся в оригинале, то автоматом без лишнего кода появятся и в плагине. А ваш плагин по определению не может дать больше чем оригинал, потому что работает поверх его АПИ, если только вы не решите сами генерить билд скрипты, но это будет вообще финиш. И вы всегда с вашим решением будете в роли остающих и будуте дорабатывать свой плагин, если оригинал даст какието новые возможности. И я не понимаю зачем мне пробовать другие решения, которые появились только что. Я закончил, не вижу больше смыслах ходить по кругу, перечитываю свои ответы и ловлю себя на мысли что в каждом абзаце у меня одно и тоже. А вы или не хотите понять или троллите меня или пытаетесь продать ваше решение.
Такое впечатление, что между словами вы хотели написать "Странно, что вы не комментируете", но пропустили "не".
Я написал ровно то что хотел написать. В первом сообщении я сам указал что лицензии нет. И думал что объяснять излишнее - что это значит что код не под свободной лицензией. И далее указал что никто не мешает самим реализовать похожий подход. Ровно так же как вы реализовали подход из IDEA Spring Ultimate.
Чтобы обратить внимание на то, что среди перечисленных вами недостатков нет ничего, что касается удобства использования?
Я же явно написал, что удобно/неудобно это явная субъективщина. Инженер не может оперировать такими понятиями. Или должен указывать что конкретно не удобно. Я вам уже на это указал - на субъектвиность. Мне удобен start-spring-boot, вам - ваше решение и тут у меня нет вопросов. Вопрос в ресурсах которые на это затрачиваются. Можно и по воробьям из пушки стрелять. Если они у вас есть - то хорошо, согласен - это не мое дело. Я лишь сказал свое мнение, что это оверкил с кучей потенциальных граблей и указал их и альтернативное решение. Пример с artefactId(пробел) - принимаю, но это мизер, по сравнению с перечисленными граблями.
Для того, чтобы можно было это сделать нужно сначала сказать чем неудобен и какую проблему не решает start-spring-boot?
По моему это вы должны ответить на этот вопрос, а не я. Обычно когда делают новый инструмент, то изучают текущие решения и их проблемы.
Тогда почему вы не написали об этом раньше? Почему раньше вы написали, что будете использовать start-spring-boot т.к. сами придерживаетесь подобного подхода и уважаете такие решения?
Вы сейчас серьезно? у меня такое ощущение что вы или троллите или издеваетесь надо мной. Вы сами в своем ответе написали про "кусок браузера". Т.е. это не очевидно что он по умолчанию дает 100% возможностей от оригинала? С вами очень трудно из за этого вести диалог. Так можно докапаться до любого слова: что да это "да", а нет это "нет". А уважаю я его именно за то что оно дает 100% возможностей оригинала с минимум усилий, настоящий инженерный подход - разве это не очевидно?
Кстати, какие проблемы сейчас не решает Init Spring?
Для меня он решает все проблемы. Но если у вас есть какито нарекания то я уже два поста подряд прошу их озвучить. А вы все одно - удобно/неудобно или адресуете этот вопрос мне непонятно зачем.
Вам трудно вести конструктивный диалог, потому что вам кто-то в интернете поставил минус
Нет - мне трудно потомучто вы ничего по существу так и не пишете. Но все мои посты с конкретными аргументами кто то минусит. Но ок - я вам верю, что это не вы. В конце концов у нас тут джентельмены собрались))) как в анекдоте.
Ну в общем, когда речь идёт об использовании плагина, то понятное дело речь пойдёт о том, удобно им пользоваться или нет. Странно, что вы об этом ничего не говорите ))
Для этого нужны конкретные аргументы. А вы их так и не говорите. Мы ходим по кругу. Я вот часами сижу думаю как лучше отвтеить - у вас в каждом абзаце одно и тоже почти - удобно/неудобно. а что не удобно так и не понятно. Разработчик 99% времени в IDE проводит в редакторе кода/конфигов, а проекты создаются на порядки реже... Я даже не представляю какие "колосальные нравственные страдания" надо испытать при создание проекта в https://start.spring.io/ чтобы об этом что то еще говорить.
Не очень понятно причем тут это? Продукт бесплатный и доступен в РФ без ВПН. Лизензия лишь запрещает открытое копирования и устанаваливает правообладателя - что по моему весьма логично.
Правда нет лицензии. То есть код открыт не больше, чем скачанные с торрентов исходники Windows ))
Странно что вы коментируете то, что я явно указал в своем исходном коментарии: "правда там нет лицензии. Но никто не мешает самому реализовать..."
Вам же никто не помешал реализовать такую же стратегию как в ультимейт СпрингИнит плагине, несмотря на его лицензию?
Интересно, что среди перечисленных вами недостатков нет ни одного, который бы касался того, насколько удобно этим плагином пользоваться.
Чтобы так говорить, нужно сначала сказать чем неудобен и какую проблему не решает start-spring-boot. Но вы не назвали ни одного, вместо этого ограничиваетесь макисмально асбтарктными фразами. Я же вам привел целых 5 минусов. Давайте говорить по существу.
То есть вы будете использовать start-spring-boot не потому что он удобнее, а из уважения к таким решениям ))
Нет, я буду пользоваться им потомучто он на 100% идентичен оригиналу и решает ВСЕ проблемы. Опять у вас максимально асбтрактные фразы, без конкретики. А уважения он заслуживает как минимум за то что он предложил простое и эффективное алтьтернативное решение, до которого почему то никто не додумался.
Достаточно сложно делать плагин, когда тебе говорят, что уже есть плагин, который вставляет в IDE кусок браузера. И понимать, что хотя ты можешь сделать удобнее и красивее, ради этих последних 20% UX тебе придётся проделать ещё 80% работы, которую не факт что кто-то оценит.
Особенно сложно делать плагин, когда не понятно какую проблему он решает и в чем его плюсы - что нового он привносит по сравнению с уже готовым? Я так и быть за вас назову один плюс - что плагин можно будет скачать без ВПН. Эти 80% работы никто не оценит потомучто она не имеет никакого смысла. По факту не решает никакой проблемы и потенциально еще столько же ресурсов отнимет на поддержку. Именно это я и хотел сказать в своих минусах что перечислил. И это не просто "кусок браузера" как вы сказали, команда спринг поддерживает также и мобильную верстку, и данным плагином удобно пользоваться даже не маленьких экранах ноутбука, и все ресурсы на это тратит Спринг, а не мы. Именно это я и пытался донести в своем сообщении, но вы или не поняли или не хотите понять. Но с вами трудно вести конструктивный диалог, учитывая реакцию под постами - минусы, и что вы по факту не назвали ни одного аргумента, а ограничились максимально абстрактными фразама - удобно/неудобно что 100% субъективщина.
Сейчас работаю над плагином под кодовым названием Cron Hints. Это снова будет аналог функциональности из Ultimate - подсказки с расшифровкой cron-выражений.
Это уже тоже давно реализовано для Spring проектов (через сode folding hotkeys), в достаточно легковесном плагине Explyt Spring, который также бесплатный и имеет открытый исходный код.
Честно говоря странное решение(ИМХО), особенно когда уже есть бесплтаная альтернатива, да еще и с открытым кодом, правда там нет лицензии. Но никто не мешает самому реализовать такую же макисмально простую и надежную стратегию как у автора оригинала, где за пару лет уже более 226к скачиваний. А у решения что описано в статье полно недостаков:
если появится новый компонент или возомжность в start.spring.io то придется дорабатываться
много ручной верстки, ради того чтобы сверстать ЮИ на платфорамнных компонентах, api которых иногда меняется, сам наступал на такое уже пару раз и придется вносить изменения
также могут поменяться гайдлайны UI/дизайн/стили в платфомре, что опять может потребовать вносить изменения
также мы завязываемся на спринг-старт рест апи, и если там что то изменится, то опять все сломается
ну и реализация что я привел выше, намного проще, как следствие стабильнее и меньше вероятность потенциальных ошибок.
Как старт чтобы вкатиться в мир плагинописания, конечно вариант... но я по прежнему буду использовать start-spring-boot т.к. сам придерживаюсь подобного подхода и уважаю такие решения где с помощью минимальных телодвижений можно дать максимально полный и стабильный функционал и которые привносят какуюто новую идею и подход.
А так мы получаем очень много потенциальных затрат на поддержку, ради такого простого и маленького функционала.
Спасибо, надо будет не полениться и настроить себе фильтр на "популярные" свежие issue.
Как-то именно в 2025.х версиях стал замечать намного больше проблем
Да вы правы. Я еще помню в 2019 году для себя уяснил правило, что не надо обновляться сразу на новые версии, лучше подождать минимум первого патча. Я до сих пор еще не обновился на 2025.3) Хотя при разработке плагинов для нее уже видно, что стек-трейсов в консоле отладчика стало сильно больше)
Что касается Мавен, то да у них там все сильно переусложнено. Собственно поэтому я и сделал свой плагин. Потомучто видел там проблемы о которых попытался рассказать в своей статье. У них там и свой кастомный МавенДемон и свой парсер билд файлов... Понятно что юзеры бывают разные. И для новичков это конечно может быть полезно когда ИДЕ за него исправляет/подсказывает ошибки, но лично мне всегда хватало вывода в консоль Мавен процесса, поэтому я и сделал свой плагин - который по сути тупо прокси/маппер над оригинальным Maven и я устал, работая там, фиксить одни и теже баги из разряда - что в оригинальном Мавен что то изменилось, а у мы еще не доработались.
В комментариях к проблеме много пользователей также на linux/ubuntu - можно сделать поиск по странице. У коллеги на работе это воспроизвелось на Mac. Мне повезло я пока не обновлялся до 2025.3. Может и у вас старая версия? проблема гарантированно есть в 2025.3.1 и 2025.2.6.
Проблема точно не в ОС и возможно она "плавающая" и не воспроизводится стабильно.
Инкрементальное обновление до сих пор сломано - например, периодически сбрасываются выбранные профили
А вы не знаете если issue по этим проблемам? нет ли ссылочек?
А по поводу проблем... они есть в любом продукте, но когда обновление наглухо вешает IDE, что приходится убивать процесс и не помогает перезапуск, что приходить удалять руками папки с кешами, чтобы она запустилась.. это все же совсем другой уровень)
Я уже спрашивал про OpenIDE тут, но как то все очень сложно, через заявки и нет механизма чтобы самому выкатывать апдейты, а они у меня случаются очень часто т.к. плагин все же местами сыроват, и все что нахожу сам или репортят пользователи стараюсь исправлять сразу. Без нормально АПИ по аплоуду артефактов, тяжело с этим работать, если я правильно все понял.
На всякий случай, я все релизы также выкладываю на GitHub, на случай проблем с доступом к JBMarketplaca, но согласен что с маркета конечно обновляться удобнее и обновления прилетают сами. P.S. Помогаторов у меня кстати нету) И еще интересный момент, в GigaIDE маркете, есть мой плагин. Неожиданно... кстати можно прописать урл на их маркет. Как это сделать было упомянуто тут. Но там правда старые версии и я не знаю кто их обновляет... сейчас там нету для 252..
Там просто вложения по дефолту видны мне и jb-team. исправил область видимости - теперь видно всем. Я думаю ПР делать нет смысла, будет тоже что и с патчем. Это уже известная история) А то что можно добавить в ОпенИДЕ и/или ГигаИДЕ идея хорошая.
Ну, и ещё в тулбаре тул-окна 2 кномки "Analyze Dependency" работает только вторая
Да такая проблема есть и она в платформе. Это действительно action от Gradle, я заводил issue на эту тему и дажк прикладывал патч. но воз и ныне там. Видно страной не вышел)
дерево необновляемое
Если честно я так сделал специально - думал чем проще тем лучше. Но в целом я с вами согласен и дефолтный плагин вроде перестраивает дерево. Попробую что нибудь с этим сделать
UPD: Вспомнил почему так сделал. В дефолтном мавене он все зависимости получает в момент "релоад" проекта, а в аналайзере просто из отображает. Поэтому у них после релоада ничего не стоит перестрить вью. У меня же надо запускать отдельный таск.. и если проект большой это может быть не то что пользователь ожидает - что у него на экране будет крутиться прогресс в окне аналайзера достаточно продолжительное время
Еще раз спасибо за обратную связь. Мало кто ее оставляет, поэтому иногда приходится действовать, исходя из своих потребностей. Например недавно добавил action для перехода к локал.репо. Вообщем не стесняйтесь в случае чего заводить issues) У меня конечно есть еще идеи чтобы сделать более удобный поиск зависимостей в мавен централ, по аналогии c maven-dependency-helper , но с другой стороны если есть плагин который эту проблему решает, то зачем...
Maven Helper строит дерево не с теми версиями
Данный плагин - это надстройка над дефолтным плагином и соотвесвенно версии он берет из него. И если дефолтный плагин не справился, то да будет проблема. О проблемах дефолтного плагина и его резолва зависимостей я пытался расказать в первой части.
В моем плагине тоже есть возможность построения дерева зависимостей. Оно также работет через мавен таск и в консоле виден процесс запуска. Надеюсь оно тоже вам помогает. Чтобы его открыть нужно кликнуть на ноде 'Dependencies' в тул окне EasyMaven для требуемого модуля.
Это идеально подходит для async-роутов Ktor: нет "пробок", выше пропускная способность под нагрузкой. Закрывает потребность в reactive Spring (R2DBC) и/или бойлерплейта.
У меня для вас плохие новости. Это никак не заменят асинхронный драйвер для работы с БД. Обернув обычный синхронный драйвер в suspend вы не получити никакого выигрыша, т.к. все будет упираться в пул соединений к БД при синхронном взаимодействии с ней. И система как была блокирующей по сути так и останется.
Атомарные операции гарантируют, что операция будет выполнена полностью и никакой другой поток не сможет изменить значение переменной до завершения операции. Это обеспечивается блокировкой переменной
Ну ну... Вы бы хоть про CAS (compare and swap) операции для начала что нибудь почитали, прежде чем писать откровенную чушь или исходники глянули. Нет там никаких блокировок. Какие сеньоры сейчас, такие и статьи.
Нет, я рассуждаю с позиции человека, который прежде чем делать что то новое изучает текущие решения.
Вам очевидно что он дает 100% возможностей, но вам не очевидно почему я выбрал его, очень странно... особено учитывая что данный плагин появился в 23 году, а ваш только что. Действительно не очевидно.
Ээээ... с чего вы это решили?
Я как раз наоборот ценю инженерный подход, мне нравится и то что он закрывает все 100% потребностей, и то что в его основе лежит простая и надежная, как автомат калашников идея и то что он занимает всего 20кб. Зачем мне пробовать какие то альтернативы? Я именно "один из них", кто не любит писать код, ради кода, кто ценит идею - ее простоту и надежность. И для меня самый лучший код тот - который я не написал. И именно поэтому в свое время выстрелили такие плагины как MavenHelper, MavenDependecyHelper, да и "Start Spring Boot Project", потомучто они привнесли что то новое, чего не было в оригинальных плагинах, а не были "такими как все". Именно поэтому они и набрали сотни тысяч и миллионы скачиваний, именно благодаря инженерному подходу и свежему взгляду на проблему и решили проблемы, людей про которых вы сказали "выбирают софт не потому что в нём есть 100% возможностей". Именно это и натолкнуло меня на все написанные мной плагины - что есть "болевые точки" нерешеные проблемы в тех решениях с которыми я работал.
Потомучто он появился в 23 году, и закрывает все мои потребности и содержит всего 5 классов и он прост и надежен. И с ним не будет такого что при очередном обновлении IDEA или SpringBoot Rest API он превратится в тыкуву. Точнее это конечно может быть, но вероятности намного меньше чем у вашего решения и я перечислил в пером сообщении все потенциальные точки отказа. Зачем мне пробовать что то новое - особенно если очевидно, что оно не дает ничего нового.
Мы точно ходим по кругу. Я увидел только один аргумент - про валидацию артефактИд. А удобно/неудобно это ваше субъективное ощущение. Я вам перечислил 5 минусов данного решения. Или оспорте их или приведите вашу аргументы почему ваш плагин лучше, также по пунктам, как это сделал я. А то в больших абзацах текста что вы пишите я не мог ничего разглядеть кроме того что вам лично удобно, Мне удобен - start-spring-boot. И у вас в маркетплейсе нет даже ссылки на исходный код вашего решения.
Опять 25. Мне всего хаватает в "start-spring-boot". Потому что это на 100% оригинал и в будущем его не надо будед дорабатывать под новоые возможности, если они появтся в оригинале, то автоматом без лишнего кода появятся и в плагине. А ваш плагин по определению не может дать больше чем оригинал, потому что работает поверх его АПИ, если только вы не решите сами генерить билд скрипты, но это будет вообще финиш. И вы всегда с вашим решением будете в роли остающих и будуте дорабатывать свой плагин, если оригинал даст какието новые возможности. И я не понимаю зачем мне пробовать другие решения, которые появились только что.
Я закончил, не вижу больше смыслах ходить по кругу, перечитываю свои ответы и ловлю себя на мысли что в каждом абзаце у меня одно и тоже. А вы или не хотите понять или троллите меня или пытаетесь продать ваше решение.
Я написал ровно то что хотел написать. В первом сообщении я сам указал что лицензии нет. И думал что объяснять излишнее - что это значит что код не под свободной лицензией. И далее указал что никто не мешает самим реализовать похожий подход. Ровно так же как вы реализовали подход из IDEA Spring Ultimate.
Я же явно написал, что удобно/неудобно это явная субъективщина. Инженер не может оперировать такими понятиями. Или должен указывать что конкретно не удобно. Я вам уже на это указал - на субъектвиность. Мне удобен start-spring-boot, вам - ваше решение и тут у меня нет вопросов. Вопрос в ресурсах которые на это затрачиваются. Можно и по воробьям из пушки стрелять. Если они у вас есть - то хорошо, согласен - это не мое дело. Я лишь сказал свое мнение, что это оверкил с кучей потенциальных граблей и указал их и альтернативное решение. Пример с artefactId(пробел) - принимаю, но это мизер, по сравнению с перечисленными граблями.
По моему это вы должны ответить на этот вопрос, а не я. Обычно когда делают новый инструмент, то изучают текущие решения и их проблемы.
Вы сейчас серьезно? у меня такое ощущение что вы или троллите или издеваетесь надо мной. Вы сами в своем ответе написали про "кусок браузера". Т.е. это не очевидно что он по умолчанию дает 100% возможностей от оригинала? С вами очень трудно из за этого вести диалог. Так можно докапаться до любого слова: что да это "да", а нет это "нет". А уважаю я его именно за то что оно дает 100% возможностей оригинала с минимум усилий, настоящий инженерный подход - разве это не очевидно?
Для меня он решает все проблемы. Но если у вас есть какито нарекания то я уже два поста подряд прошу их озвучить. А вы все одно - удобно/неудобно или адресуете этот вопрос мне непонятно зачем.
Нет - мне трудно потомучто вы ничего по существу так и не пишете. Но все мои посты с конкретными аргументами кто то минусит. Но ок - я вам верю, что это не вы. В конце концов у нас тут джентельмены собрались))) как в анекдоте.
Для этого нужны конкретные аргументы. А вы их так и не говорите. Мы ходим по кругу. Я вот часами сижу думаю как лучше отвтеить - у вас в каждом абзаце одно и тоже почти - удобно/неудобно. а что не удобно так и не понятно. Разработчик 99% времени в IDE проводит в редакторе кода/конфигов, а проекты создаются на порядки реже... Я даже не представляю какие "колосальные нравственные страдания" надо испытать при создание проекта в https://start.spring.io/ чтобы об этом что то еще говорить.
Не очень понятно причем тут это? Продукт бесплатный и доступен в РФ без ВПН. Лизензия лишь запрещает открытое копирования и устанаваливает правообладателя - что по моему весьма логично.
Странно что вы коментируете то, что я явно указал в своем исходном коментарии: "правда там нет лицензии. Но никто не мешает самому реализовать..."
Вам же никто не помешал реализовать такую же стратегию как в ультимейт СпрингИнит плагине, несмотря на его лицензию?
Чтобы так говорить, нужно сначала сказать чем неудобен и какую проблему не решает start-spring-boot. Но вы не назвали ни одного, вместо этого ограничиваетесь макисмально асбтарктными фразами. Я же вам привел целых 5 минусов. Давайте говорить по существу.
Нет, я буду пользоваться им потомучто он на 100% идентичен оригиналу и решает ВСЕ проблемы. Опять у вас максимально асбтрактные фразы, без конкретики. А уважения он заслуживает как минимум за то что он предложил простое и эффективное алтьтернативное решение, до которого почему то никто не додумался.
Особенно сложно делать плагин, когда не понятно какую проблему он решает и в чем его плюсы - что нового он привносит по сравнению с уже готовым? Я так и быть за вас назову один плюс - что плагин можно будет скачать без ВПН.
Эти 80% работы никто не оценит потомучто она не имеет никакого смысла. По факту не решает никакой проблемы и потенциально еще столько же ресурсов отнимет на поддержку. Именно это я и хотел сказать в своих минусах что перечислил. И это не просто "кусок браузера" как вы сказали, команда спринг поддерживает также и мобильную верстку, и данным плагином удобно пользоваться даже не маленьких экранах ноутбука, и все ресурсы на это тратит Спринг, а не мы. Именно это я и пытался донести в своем сообщении, но вы или не поняли или не хотите понять.
Но с вами трудно вести конструктивный диалог, учитывая реакцию под постами - минусы, и что вы по факту не назвали ни одного аргумента, а ограничились максимально абстрактными фразама - удобно/неудобно что 100% субъективщина.
Это уже тоже давно реализовано для Spring проектов (через сode folding hotkeys), в достаточно легковесном плагине Explyt Spring, который также бесплатный и имеет открытый исходный код.
Честно говоря странное решение(ИМХО), особенно когда уже есть бесплтаная альтернатива, да еще и с открытым кодом, правда там нет лицензии. Но никто не мешает самому реализовать такую же макисмально простую и надежную стратегию как у автора оригинала, где за пару лет уже более 226к скачиваний. А у решения что описано в статье полно недостаков:
если появится новый компонент или возомжность в start.spring.io то придется дорабатываться
много ручной верстки, ради того чтобы сверстать ЮИ на платфорамнных компонентах, api которых иногда меняется, сам наступал на такое уже пару раз и придется вносить изменения
также могут поменяться гайдлайны UI/дизайн/стили в платфомре, что опять может потребовать вносить изменения
также мы завязываемся на спринг-старт рест апи, и если там что то изменится, то опять все сломается
ну и реализация что я привел выше, намного проще, как следствие стабильнее и меньше вероятность потенциальных ошибок.
Как старт чтобы вкатиться в мир плагинописания, конечно вариант... но я по прежнему буду использовать start-spring-boot т.к. сам придерживаюсь подобного подхода и уважаю такие решения где с помощью минимальных телодвижений можно дать максимально полный и стабильный функционал и которые привносят какуюто новую идею и подход.
А так мы получаем очень много потенциальных затрат на поддержку, ради такого простого и маленького функционала.
Спасибо, надо будет не полениться и настроить себе фильтр на "популярные" свежие issue.
Да вы правы. Я еще помню в 2019 году для себя уяснил правило, что не надо обновляться сразу на новые версии, лучше подождать минимум первого патча. Я до сих пор еще не обновился на 2025.3) Хотя при разработке плагинов для нее уже видно, что стек-трейсов в консоле отладчика стало сильно больше)
Что касается Мавен, то да у них там все сильно переусложнено. Собственно поэтому я и сделал свой плагин. Потомучто видел там проблемы о которых попытался рассказать в своей статье. У них там и свой кастомный МавенДемон и свой парсер билд файлов... Понятно что юзеры бывают разные. И для новичков это конечно может быть полезно когда ИДЕ за него исправляет/подсказывает ошибки, но лично мне всегда хватало вывода в консоль Мавен процесса, поэтому я и сделал свой плагин - который по сути тупо прокси/маппер над оригинальным Maven и я устал, работая там, фиксить одни и теже баги из разряда - что в оригинальном Мавен что то изменилось, а у мы еще не доработались.
В комментариях к проблеме много пользователей также на linux/ubuntu - можно сделать поиск по странице. У коллеги на работе это воспроизвелось на Mac. Мне повезло я пока не обновлялся до 2025.3. Может и у вас старая версия? проблема гарантированно есть в 2025.3.1 и 2025.2.6.
Проблема точно не в ОС и возможно она "плавающая" и не воспроизводится стабильно.
А вы не знаете если issue по этим проблемам? нет ли ссылочек?
А по поводу проблем... они есть в любом продукте, но когда обновление наглухо вешает IDE, что приходится убивать процесс и не помогает перезапуск, что приходить удалять руками папки с кешами, чтобы она запустилась.. это все же совсем другой уровень)
Да, мой плагин есть в JetBrains Marketplace https://plugins.jetbrains.com/plugin/22370-easy-maven
Что надо сделать чтобы попать в OpenIDE Marketplace?
Я уже спрашивал про OpenIDE тут, но как то все очень сложно, через заявки и нет механизма чтобы самому выкатывать апдейты, а они у меня случаются очень часто т.к. плагин все же местами сыроват, и все что нахожу сам или репортят пользователи стараюсь исправлять сразу.
Без нормально АПИ по аплоуду артефактов, тяжело с этим работать, если я правильно все понял.
Спасибо.
На всякий случай, я все релизы также выкладываю на GitHub, на случай проблем с доступом к JBMarketplaca, но согласен что с маркета конечно обновляться удобнее и обновления прилетают сами.
P.S. Помогаторов у меня кстати нету) И еще интересный момент, в GigaIDE маркете, есть мой плагин. Неожиданно...
кстати можно прописать урл на их маркет. Как это сделать было упомянуто тут.
Но там правда старые версии и я не знаю кто их обновляет... сейчас там нету для 252..
Если есть время можно попробовать промежуточные сборки. Доступны для 251 и 252 версии.
Там просто вложения по дефолту видны мне и jb-team. исправил область видимости - теперь видно всем. Я думаю ПР делать нет смысла, будет тоже что и с патчем. Это уже известная история) А то что можно добавить в ОпенИДЕ и/или ГигаИДЕ идея хорошая.
Да такая проблема есть и она в платформе. Это действительно action от Gradle, я заводил issue на эту тему и дажк прикладывал патч. но воз и ныне там. Видно страной не вышел)
Если честно я так сделал специально - думал чем проще тем лучше. Но в целом я с вами согласен и дефолтный плагин вроде перестраивает дерево. Попробую что нибудь с этим сделать
UPD: Вспомнил почему так сделал. В дефолтном мавене он все зависимости получает в момент "релоад" проекта, а в аналайзере просто из отображает. Поэтому у них после релоада ничего не стоит перестрить вью. У меня же надо запускать отдельный таск.. и если проект большой это может быть не то что пользователь ожидает - что у него на экране будет крутиться прогресс в окне аналайзера достаточно продолжительное время
Еще раз спасибо за обратную связь. Мало кто ее оставляет, поэтому иногда приходится действовать, исходя из своих потребностей. Например недавно добавил action для перехода к локал.репо. Вообщем не стесняйтесь в случае чего заводить issues)
У меня конечно есть еще идеи чтобы сделать более удобный поиск зависимостей в мавен централ, по аналогии c maven-dependency-helper , но с другой стороны если есть плагин который эту проблему решает, то зачем...
Данный плагин - это надстройка над дефолтным плагином и соотвесвенно версии он берет из него. И если дефолтный плагин не справился, то да будет проблема. О проблемах дефолтного плагина и его резолва зависимостей я пытался расказать в первой части.
В моем плагине тоже есть возможность построения дерева зависимостей. Оно также работет через мавен таск и в консоле виден процесс запуска. Надеюсь оно тоже вам помогает. Чтобы его открыть нужно кликнуть на ноде 'Dependencies' в тул окне EasyMaven для требуемого модуля.
Спасибо большое. Если не сложно могли бы вы написать какие проблемы для вас он решает с которыми не справился дефолтный плагин?
del. промазал с ответом.
У меня для вас плохие новости. Это никак не заменят асинхронный драйвер для работы с БД. Обернув обычный синхронный драйвер в suspend вы не получити никакого выигрыша, т.к. все будет упираться в пул соединений к БД при синхронном взаимодействии с ней. И система как была блокирующей по сути так и останется.
Без ложной скромности)))
Ну ну... Вы бы хоть про CAS (compare and swap) операции для начала что нибудь почитали, прежде чем писать откровенную чушь или исходники глянули. Нет там никаких блокировок. Какие сеньоры сейчас, такие и статьи.