Всем привет! На связи команда 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 в наш плагин. И это также позволило переиспользовать для него многие другие наши «фичи», о чем будет рассказано ниже.

Всем привет! Одной из уникальных особенностей нашего плагина, является практически стопроцентное понимание контекста 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 плагина.