Всем привет! Недавно я опубликовал статью, в которой сказал что она будет последней по Easy Maven т.к. все что можно я уже делегировал Maven — импорт проекта, запуск тасков, анализ зависимостей. Но недавнее обилие багов в IDEA 2025.3 связанных как с зависанием так и повышенным потреблением памяти Maven проектами, окунуло меня в баг трекер IDEA, где я нашел много похожих проблем, которые также затрагивают и мавен индексы. Помню как меня самого это раздражало, когда IDEA чуть ли не при каждом открытии, начинает сканировать локальный репозиторий. Про это даже писали в комментариях — где ответ был один — отключить это. Плюс недавно один из постов в тг канале (спасибо за это @javadev), еще больше убедил меня в том, что так дальше жить нельзя и я решил поправить проблему поиска зависимостей так как я ее вижу — не изобретать велосипед, а делегировать поиск туда, где это уже реализовано. Ведь как известно: самый лучший код — тот который ты не написал. Посмотрим что из этого вышло.

Всем привет. Ранее я уже публиковал статьи (раз и два), где рассказывал о проблемах IDEA Maven плагина, основная из которых — это импорт проектов. И о своем решении Easy Maven, как получить информацию о проекте с помощью нативного Maven плагина. Теперь я бы хотел поговорить о запуске и отладке проектов в IDEA. С ними на самом деле похожая проблема. Чтобы это все работало, нужно импортировать в IDEA все настройки компилятора из билд файлов, чтобы среда разработки могла сама компилировать и запускать проект. Но это не так то просто — постоянно появляются новые параметры и возможности компиляторов, также для каждого из JVM языка (Java, Kotlin, Groovy, Scala и так далее) есть свой компилятор со своими особенностями, annotation processors — которые надо дополнительно распознавать и загружать как jar‑файлы с их транзитивными зависимостями и импортировать в IDEA. Постоянно нужно за всем этим следить и нам опять приходить играть в догонялки. Только мы всегда находимся на шаг позади в роли отстающих и нужно тратить много ресурсов, чтобы заставить запускаться проект корректно из IDEA. Поэтому я решил и тут пойти другим путем — а зачем нам вообще все это делать и переносить настройки в IDEA, если мы можно просто выполнить Maven таск для соответствующего плагина — запуск теста или приложения? Поэтому я хотел бы остановиться на этом поподробнее и рассказать о своем решении.

Всем привет! На связи команда Explyt Spring. Недавно у нас вышел очередной релиз, который включает несколько важный обновлений: поддержа SQL, очередные улучшения для Spring Debugger, поддержка Spring пропертей для Docker-Compose файлов и многое другое. Если вам интересны подробности то добро пожаловать под кат!

Всем привет, на связи команда Explyt. Как известно наша компания предоставляет целую экосистему плагинов для IDEA: это и плагин для поддержки Spring, а также Explyt плагин для написания кода, генерации тестов и интеграции с AI. И нам пришла в голову идея - а почему бы не расширить функциональность Spring плагина с помощью AI ассистента, который есть в Explyt. И если вы используете оба наши плагина, то у вас появятся дополнительные возможности для Spring, позволяющие достаточно хорошо решать типовые задачи, которые возникают в процессе работы, с помощью AI, о которых мы подробно расскажем далее.

Всем привет! На связи команда Explyt Spring. Недавно была статья от JetBrains, а также ее перевод на Habr, где они рассказывали о новом плагине Spring Debugger и о том как используют нативный код Spring для лучшего понимания контекста приложения. С помощью non‑suspending breakpoints JetBrains «вклиниваются» в жизненный цикл Spring и собирают все необходимые для плагина данные. Но ведь это почти тоже что и мы пытались делать в нашем плагине с помощью javaagent, о котором писали статьи. И нам даже показалось, что они вдохновлялись нашими статьями, первая из которых увидела свет в октябре 2024 года (возможно только показалось).

Нужно отдать должное тому как они интегрировали эту идею в плагин — данные о контексте сами подгружаются в процессе дебага, максимально прозрачно для пользователя и без лишних действий с его стороны. У нас же, требовалось загружать контекст приложения вручную, выбрав соответствующую «ран» конфигурацию, на основе которой мы получали данные о приложении, что стало предметом конструктивной критики со стороны пользователей.

Нам эта идея понравилась, к тому же у нас почти все готово — есть javaagent с помощью которого мы патчим байт код Spring и получаем его контекст, поэтому возьмем текущий наш механизм и просто улучшим UX и посмотрим что из этого получилось.

Всем привет! На связи команда Explyt Spring. На этот раз как следует из названия будем говорить о поддержке Quarkus. На первый взгляд может показаться странным, причем тут Spring плагин и Quarkus. Но если разобраться более детально, то Spring также имеет поддержку Java EE аннотаций и к тому же поддержка Dependency Injection является одной из сильной сторон нашего плагина. Да и логика DI в Quarkus сильно проще чем в Spring, можно убедиться в этом прочитав официальную документацию, поэтому можно легко переиспользовать все наши текущие наработки и добавить поддержку Quarkus DI в наш плагин. И это также позволило переиспользовать для него многие другие наши «фичи», о чем будет рассказано ниже.

Всем привет! На связи команда Explyt Spring (GitHub). Одной из уникальных особенностей нашего плагина, является практически стопроцентное понимание контекста Spring приложений. Где мы максимально нативным способом, через публичное Spring Boot Api, смогли получить доступ к контексту приложения и использовали эту информацию у себя в плагине для поддержки Spring Dependency Injection и навигации к «бинам». Но время не стоит на месте, и мы сделали еще один шаг в сторону улучшения распознавания Spring Context, путем модификации текущего байт‑кода Spring через параметр jvm: -javaagent, который позволил избавиться нам от большинства недостатков текущего подхода, кому интересно узнать детали реализации, то добро пожаловать под кат.

Всем привет. В предыдущей статье мы рассказывали о нашей версии HTTP клиента, которая основана на генерации OpenAPI файлов по Spring-контроллерам и Swagger UI в качестве готового интерфейса пользователя для работы с запросами. В комментариях к ней писали, что поддержка http файлов весьма актуальна, так как они используются во многих существующих проектах. Мы решили изучить этот вопрос подробнее и вот что из этого вышло…

Всем привет. Более года назад я публиковал на Хабр статью, где рассказывал о проблемах IDEA Maven плагина, о том что с этим можно сделать и представил свою версию плагина. Основная проблема которую он решает - это импорт проектов в IDEA. На тот момент это был прототип решения. За это время у меня появилось ~300 активных пользователей, добавлена поддержка MVND и WSL. И спустя год, хотел бы рассказать о изменениях которые произошли в моем плагине более подробно, а ближе к концу статьи о свежих примерах ошибок импорта проектов в IDEA, которые смог решить мой плагин.

Всем привет! Как следует из названия статьи, речь пойдет о HTTP-клиентах для IntelliJ IDEA, да, опять). В последнее время было несколько публикаций на эту тему, и мы бы хотели подробно рассказать о нашем взгляде на эту проблему и нашей реализации. А также поговорить о плюсах и минусах текущих решений для IDEA. Ранее мы уже рассказывали о нашем плагине для Spring - о том как у нас реализована поддержка Dependency Injection в частности, теперь настала очередь HTTP client'а.

Всем привет. После моей предыдущей статьи о Maven плагине, где я предложил новый подход к реализации и создал свою версию для IDEA (вместо того чтобы писать свой мини-мавен, я делегировал всю основную работу ему посредством Maven плагина), меня пригласили работать над Spring плагином в IT-стартап Explyt. Компания занимается автоматической генерацией тестов на базе AI и формальных методов. В процессе работы столкнулся с проблемами, похожими на те, которые решал в своем Maven плагине. У меня возникло некое дежавю, и я подумал: почему бы не использовать подобный подход, чтобы доработать и улучшить Dependency Injection Explyt Spring плагина? Текст для тех, кто работает со Spring-плагинами и хочет разобраться, как эффективно применять готовую логику Спринга для новых задач. Заходите под кат, подробно поделюсь своим кейсом, покажу код, расскажу про итерации и объясню логику.

Всем привет. На своем последнем месте работы я выполнял обязанности Java разработчика в одной из команд сервиса, чье приложение установлено в смартфоне большинства жителей РФ. Использовался стандартный стек технологий: Java, Spring(web, jdbc, core), PostgreSQL, Kafka. Обычное синхронное API по работе с данными, без всякой реактивщины, с нагрузкой более миллиона пользователей в день. Я столкнулся с тем что сервисы по работе с БД были обильно «усыпаны» Spring аннотациями @Transactional. Даже одиночные запросы на чтение данных использовали аннотацию с параметром readOnly=true. Я пытался писать комментарии к мердж‑реквестам с вопросом: «зачем вы это делаете?». Но получал ответы из разряда: «для перфоманса», «у нас так принято, чтобы случайно не упустить случай когда транзакция будет действительна нужна», «раньше у нас была какая‑то проблема с коннектами (какая именно никто так и не вспомнил сколько я не пытал), мы везде добавили аннотации и все заработало». Если интересно чем в итоге закончилась эта дискуссия, то подробности далее.

Привет, ранее я написал статью о своем плагине и том, как переосмыслил подход к получению проектной модели Maven. И обещал более подробно рассказать о технических деталях реализации плагина и точках расширения IDEA, которые использовал.

Большинство так называемых внешних систем, по отношению к IDE, соответствуют общему шаблону: имеют конфигурационные файлы, на основании конфигурационных файлов можно построить проект, предоставляют возможность выполнения каких-либо задач.

Всем этим условиям удовлетворяют популярные билд-системы: Gradle, Maven, Sbt и не только, например Docker-compose. IDEA плагины для них построены на External System API. Поэтому для написания своего плагина, я также использовал данное API и хочу рассказать о нем более подробно.

Привет, меня зовут Григорий Мясоедов, ранее я имел опыт работы в JetBrains в команде build tools, а конкретно занимался Maven-plugin.  В этой статье я хочу поговорить о том как устроен плагин под капотом, его сильных и слабых местах, и о том что я в итоге со всем этим сделал.

Одна из самых частых проблем, которыми я занимался в JetBrains, звучала так - “через командную строку Maven проект собирает, но в IDEA он не импортируется (импортируется с ошибками)”. Как будет показано ниже большинство этих проблем связаны с архитектурой JB Maven плагина.