Page History

...

 Need to define how an (abstract) "Run" action can be remapped to a different action ("run-continuous") defined in nbactions.xml. 

Definition for Maven

    <action>
        <actionName>run.continuous</actionName>
        <packagings>
            <packaging>jar</packaging>
        </packagings>
<!--
		Maybe not necessary to add, if the MavenActionsProvider itself are registered specifically per-plugin

        <activation>
            <plugin>io.micronaut.build:micronaut-maven-plugin</plugin>
        </activation>
-->
        <goals>
            <goal>process-classes</goal>
            <goal>io.micronaut.build:micronaut-maven-plugin:2.0.0:run</goal>
        </goals>
        <properties>
            <exec.vmArgs></exec.vmArgs>
            <exec.args>${exec.vmArgs} -classpath %classpath ${exec.mainClass} ${exec.appArgs}</exec.args>
            <exec.appArgs></exec.appArgs>
            <exec.mainClass>${packageClassName}</exec.mainClass>
            <exec.executable>java</exec.executable>
        </properties>
    </action>

Definition for Gradle

Display Action in the

...

IDE

Neither Gradle or Maven support adding technology-specific actions in the project UI. Even if the action is defined in nbactions.xml, it will not appear anywhere in the popup menu, except for custom actions (having CUSTOM- prefix in their action name; maven only). In this case, I would like to display the Continuous Run action alongside the Run and Debug.

...

• executes on click,
• can display a submenu which contains
  • Run once
  • Run continuous
• the new state would be remembered

Adding technology-specific actions

Common actions for a project type are placed in Projects/<project-type-id>/Actions. These actions are displayed in the Project's context menu in the filesystem-defined order. I propose to define a layer API that would include also actions from Projects/<project-type-id>/plugin-id/Actions for all plugins participating on the project:

...

 Allowing to extend the main project menu may lead to its explosion with many added actions for each technology. A standard grouping action should be created in the OpenAPI and documented, so a technology may eventually add its action into a subgroup. This will not be part of the initial implementation, but could be added later. Note that by default, the Lookups.forPath() collects the whole .../Actions subtree (traversing into subfolders).

Maven implementation

RunJar support

Current "Run" operation relies on RunJar prerequisity checker and late-bound checker to step in, and supply necessary values for ${} variables referenced in the action config. The prerequisity checker checks for specific action IDs when activating. If Micronaut support defines Continuous Run as a different action ID, these checkers will not  be used, and the action may become broken: for example application args, VM args etc as seen in the Project Properties dialog will not be processed, StartupExtenders will not be collected etc. Two (or more ?) options here:

• Micronaut plugin will duplicate the RunJar logic, or
• We export an API from Maven core "Run" support to bind that support to specific executions, so the logic could be reused
  • packaging (already done)
  • project action ID
  • active plugins
• We export an API from either Maven (but see Gradle notes below) or from Project support itself, to categorize actions. Something like boolean isKindOf(abstractActionId, actionId), with an appropriate (declarative ?) SPI that Micronaut can use to declare Continous Run is kind of Run. This way, runJar support may check for categories instead of action Ids.

The logic implemented by Maven (which can be reused by Micronaut) is:

• Selection of the main class: if not defined, UI shows up, eventually recording user's choices in nbactions.xml
• Java platform selection
• StartupExtender VM parameters merge
• ExplicitProcessParameters processing

Selection of Java platform

While exec:exec goal honours system property exec.executable, that eventually specifies the desired Java executable to be used for application launch, Micronaut maven plugin does not honour any such property and relies on toolchains in maven. NetBeans do not support toolchains much, and our LSP clients also manage JDKs in a different way, not using maven toolchains. Java platform selection will be broken for mn:run goal, unless the whole maven runs on the target JDK.

The simplest solution is to enhance the mn:run goal to support some 'exec.executable'-like (i.e. mn.executable) property with a similar semantics.

Gradle implementation

The current parameter-passing implementation could work, mostly, except that it also specifically checks for action IDs. Other than that, gradle support should work acceptably.