Новый взгляд на Maven-plugin для IDEA — GMaven

Спасибо. Теоретически, именно за счет автономности maven-plugin, с таким подходом можно с небольшими усилиями добавить поддержку maven для любой IDE.

GMaven Plus это плагин для Maven.
Мой GMaven это плагин для IDEA. И с аналогичным именем в IDEA Marketplace других плагинов нет. К тому же я не уверен что имя плагина должно быть уникальным, в отличии от plugin id.

Спасибо за обратную связь! Интересный use case. Еще одно доказательство того, что нет ничего лучше чем полноценный maven lifecycle для импорта проекта) Если найдете какие то проблемы, то смело пишите в лс. А как раньше вы работали со своим проектом - Eclipse?

активируясь во время фазы validate, меняет версии некоторых зависимостей

Это зачем такой трюк?

Я еще подумал над вашим кейсом - использование дополнительных maven-task при импорте. И нашел одну неприятную особенность, сейчас так задумано что ‘maven agrs’ передаются по все внутренние процессы плагина, будь то импорт проектной модели или запуск таска. И при запуске тасков это выглядит избыточно, особенно при clean. Основной вариант использования(по моему мнению) mvn agrs - это переопределение стандартных настроек Maven во всех процессах плагина (кастомные сеттинги -s /home/settings.xml, локальный репо -Dmaven.repo.local=/home/my_repository и прочее). Поэтому я решил сделать отдельную настройку ‘Import args’ для указания дополнительных аргументов, который будут использоваться только при импорте.
Будет вот так (в ближайшее время выложу новую версию в основной Marketplace, уже не alpha):

Additional args - будут добавляться во все maven процессы, включая импорт. Основное назначение переопределять во всех процессах базовые Maven параметры. Для частных случаев можно создать Run Configuration. 

Import args - только для импорта.

Потому что плагины для IDE не пишутся с чистого листа. Для IDEA плагинов есть свой шаблон, встроенный в стандартный wizard. Который использует Gradle и обеспечивает базовый флоу написания плагинов - их запуск, отладку, публикацию в marketplace и прочее. И заниматься изысканиями на тему, а можно ли это переделать на Maven, я не видел смысла, т.к. решал совсем другую проблему.
Тем более официальная документация не дает альтернатив. А поиск решений для Maven, находит только не активные проекты вроде - https://plugins.jetbrains.com/plugin/7127-intellij-plugin-development-with-maven/versions и https://maven.apache.org/plugins/maven-idea-plugin/

Пока никак, т.е. специально для этого я ничего не делал. Но как показывает практика - все не так уж и плохо) Если сгенерировать Maven/Kotlin проект через стандартный wizard и далее открыть моим плагином, то он с большой долей вероятности заработает на дефолтных IDEA Kotlin Compiler настройках. А Maven вернет корректную проектную модель с Kotlin content root’ами, благодаря параметрам - <sourceDirectory>/<testSourceDirectory> из билд файла - и все будет работать в IDE. Если создать Spring/Kotlin/Maven проект через spring initializr, то там будет еще проблема при билде проекта из IDEA, т.к. она ничего не знает про kotlin-maven-allopen. Но если сбилдить проект мавеном - package, то он сгенерит в target уже корректные “открытые” классы и все далее будет прекрасно работать в IDE. Надо будет кончено допилить эти моменты, займусь в ближайшее время)

Я не против, open source же) главное чтобы продукт развивался и становился лучше)

Начиная с версии 3.3.1 минимальная версия JDK 7+. И я посчитал что почти 10 лет это срок) поэтому также своему Maven плагину поставил минимальную версию 7. Также начиная с 3.3.1 есть ряд фич на которые есть завязки в коде - например .mvn/jvm.config. Но в целом это не мешает запускать проекты и на более ранних версия Maven, если они работают на JDK 7+. Интереса ради проверил на версии - 3.2.1 все ок. Но вот на 3.1.1 уже вылезли проблемы несовместимости API MavenSession. 
https://maven.apache.org/docs/history.html

Как я уже говорил в статье, что пока проект в стадии MVP и много кода я заимствовал из основного репозитория idea-community. Поэтому все что можно было переиспользовать я оставлял как есть. Но новый код я пишу на Котлин (лично для себя я не вижу тут большой проблемы, да и в JB никто не заставлял писать на чем то конкретно). Но учитывая что при каждом релизе IDEA, даже мне приходиться местами переписывать код, т.к. ломается обратная совместимость (поэтому у меня уже в репо появились ветки 222/223/231/232), а ваш форк имеет еще более раннюю кодовую бд, то даже код на Java не получилось бы скорее всего легко адаптировать под него и пришлось бы многое переписывать. В основном переписывать надо будет конвертеры в External API - MavenProjectResolver и в взаимодействие с Maven GServerHelper. Можем обсудить детали в лс, если будет время я готов помочь.