Спасибо, надо будет не полениться и настроить себе фильтр на "популярные" свежие 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) операции для начала что нибудь почитали, прежде чем писать откровенную чушь или исходники глянули. Нет там никаких блокировок. Какие сеньоры сейчас, такие и статьи.
1) тут нет никаких чудес - все зависит от модели которую использует LLM. И как правильно заметили выше делает это с опрделенной степенью вероятности. Основный посыл в том что мы генерим базойвый boilerplate код который гораздо проще доработать руками до нужного состоянии, чем писать руками, даже если LLM не совсем корректно справилась, о чем мы такжу упомянули в статье. Я сделал небольшой пример по вашему сценарию (скрины прикреплю ниже). Так наша дефолтная модель которую можно использовать в персональной подписке (первый месяц бесплатно), увидела что внутри есть вложенные объекты и спросила надо ли сделать для них тоже "ентити". 2) модель используется та которую вы выберете в настройках Explyt плагина. Более подробно можно прочитать тут. Поддержка локальных моделей тоже есть.
а вы зачем-то хвастаетесь что написали промпт для LLM который это тоже делает
Мы не хвастаемся этим, а поясняем во вступлении к статье, что это очень дешевый способ получения нужного функционала, который достигается путем интеграции двух наших плагинов. И как вы правильно заметили с определенной долей вероятности, о чем мы также пишем в статье, что те же конфиги скорее всего придется дорабатывать руками. Но спасибо за наводку, не скрою, я только мельком слышал про данный фрейморк, может быть в дальнейшем стоить разобраться с ним более подробно и получится затащить часть функционала без ИИ.
Почему вы заостряете внимаение только на одном моменте? Помимо это мы также генерируем 1) модель по SQL файлам 2) OpenAPI документацию из контроллеров и обратно 3) Конфиги Kafka/Security 4) http запросы из Postman/Curl 5) конвертация пропертей из разных форматов
И если даже говорить о геттерах и сеттерах, применимо к одной из самых популярных технологий на Spring - JPA, то хоть Java, хоть Kotlin - филды никуда не деваются. Или вам нравится писать их руками? Лично мне нет. И LLM прекрасно решает эту проблему также. Как и генерацию модели по SQL файлу. Не все фрейморки также как JOOQ умеют создавать модель по БД.
Тоже самое относится и к DTO. Kotlin филды за вас не напишет.
А так вам AI нагенерит кучу кода который беде лежать в репозитарии и за который придётся нести ответственность :)
А вы точно прочитали статью до конца? Или ограничились вступлением и пошли писать комментарий?
достаточно определить доменый объект и дто по желанию и все без AI
Как раз именно это мы и пытаемся автоматизировать. Практически все наши Actions о которых идет речь в статье это элементарные операции преобразования из одного в другое. И генерация DTO по JPA модели яркое тому подтверждение о чем и рассказано в статье. Чтобы не набирать шаблонный код с нуля каждый раз. И мы не пытаемся лезть в бизнес логику приложения, пользователь может сам писать ее как хочет, хоть руками с использованием своих любимых библиотек, хоть с помощью нашего AI ассистента. Поэтому вообще не понятно о чем вы пишите.
Спасибо, надо будет не полениться и настроить себе фильтр на "популярные" свежие 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) операции для начала что нибудь почитали, прежде чем писать откровенную чушь или исходники глянули. Нет там никаких блокировок. Какие сеньоры сейчас, такие и статьи.
1) тут нет никаких чудес - все зависит от модели которую использует LLM. И как правильно заметили выше делает это с опрделенной степенью вероятности. Основный посыл в том что мы генерим базойвый boilerplate код который гораздо проще доработать руками до нужного состоянии, чем писать руками, даже если LLM не совсем корректно справилась, о чем мы такжу упомянули в статье. Я сделал небольшой пример по вашему сценарию (скрины прикреплю ниже). Так наша дефолтная модель которую можно использовать в персональной подписке (первый месяц бесплатно), увидела что внутри есть вложенные объекты и спросила надо ли сделать для них тоже "ентити".
2) модель используется та которую вы выберете в настройках Explyt плагина. Более подробно можно прочитать тут. Поддержка локальных моделей тоже есть.
Спасибо за пояснение.
Мы не хвастаемся этим, а поясняем во вступлении к статье, что это очень дешевый способ получения нужного функционала, который достигается путем интеграции двух наших плагинов. И как вы правильно заметили с определенной долей вероятности, о чем мы также пишем в статье, что те же конфиги скорее всего придется дорабатывать руками.
Но спасибо за наводку, не скрою, я только мельком слышал про данный фрейморк, может быть в дальнейшем стоить разобраться с ним более подробно и получится затащить часть функционала без ИИ.
Почему вы заостряете внимаение только на одном моменте? Помимо это мы также генерируем
1) модель по SQL файлам
2) OpenAPI документацию из контроллеров и обратно
3) Конфиги Kafka/Security
4) http запросы из Postman/Curl
5) конвертация пропертей из разных форматов
И если даже говорить о геттерах и сеттерах, применимо к одной из самых популярных технологий на Spring - JPA, то хоть Java, хоть Kotlin - филды никуда не деваются. Или вам нравится писать их руками? Лично мне нет. И LLM прекрасно решает эту проблему также. Как и генерацию модели по SQL файлу. Не все фрейморки также как JOOQ умеют создавать модель по БД.
Тоже самое относится и к DTO. Kotlin филды за вас не напишет.
Не очень понимаю про что ваш коммент.
А вы точно прочитали статью до конца? Или ограничились вступлением и пошли писать комментарий?
Как раз именно это мы и пытаемся автоматизировать. Практически все наши Actions о которых идет речь в статье это элементарные операции преобразования из одного в другое. И генерация DTO по JPA модели яркое тому подтверждение о чем и рассказано в статье. Чтобы не набирать шаблонный код с нуля каждый раз.
И мы не пытаемся лезть в бизнес логику приложения, пользователь может сам писать ее как хочет, хоть руками с использованием своих любимых библиотек, хоть с помощью нашего AI ассистента.
Поэтому вообще не понятно о чем вы пишите.
del
Уже сделано)
https://habr.com/ru/companies/explyt/articles/884280/